Használsz debuggert hibakereséshez?

Előre szólok, hogy nem vagyok se programozó, se coder, de ha néha hasonló dolgot kell csinálnom, nem lennék olyan "állat", hogy mindenféle más által már kifejlesztett és elfogadott kódot újra írjak.
Nem lenne ugyanis költséghatékony.
Ha pedig már külső libet használok, bizony jól tud jönni egy jól működő debugger. Leginkább akkor, ha az ember kap egy olyan feladatot, amit az "elődje" 4 hónapos csúszással sem ad át...

"A debuggerben fejlesztes hatranyait szamomra pont a te altald leirt (edit&continue) eset peldazza. Tervezes es atgondoltsag helyett prblakozas es kiserletezgetes, ami szuksegkeppen felmegoldasokat eredmenyez."

És az miből következik számodra, hogy nem tervezem meg előre, hogy mit akarok megcsinálni, hogy részekre bontom a feladatot és egy részt letesztelek, mielőtt továbbhaladnék azon az úton, amit elterveztem?

"Mi a kulonbseg?"

Az, hogy amikor csak azt a kódot látom, ami le van írva, akkor csak annyit látok, amit elterveztem, hogy csinálnia kell a programnak. Tfh. van egy ilyen:

private void Foobar(Tralala bla1, Tralala bla2)
{
  // Paraméterek ellenőrzése

  int salala = this.IngyomBingyom.Bizbasz(bla1, bla2);
  
  if (salala > 0)
  {
    // Akarmi
  }
  else
  {
    // Valami tök más
  }
}

Látom a kódot, csinál valamit a két paraméterrel egy másik objektum, ami viszaad nekem egy intet. Futtatom két olyan bemeneti értékkel, amiről tudom, hogy a true ágnak kell lefutnia mégis a false ág fut le. (Ez az, amit leírtam). Ilyenkor jövök debuggerrel, megnézem, hogy jó paramétert kap-e a függvényem (nem-e valami másik rétegben romlott el az adat, hiába van ellenőrizve), aztán végiglépkedek a kódon. Ha látom, hogy nem jó irányba megy, akkor meg elő a Bizbasz(Tralala, Tralala) kódját és nézzük, hogy ott mit csinál. (Ez meg a viselkedése). Csak közben egy körön belül le tudom ellenőrizni, hogy valóban jó paraméter jön-e vagy a függvényhívás után van a hiba. (És ezzel máris kizártam a kód egyik felét). Különösen hasznos, mikor többrétegű alkalmazást fejlesztesz vagy több külön alrendszer működik együtt. (Amit mondjuk opcionálisan két külön csapat fejleszt). De ugyanígy debuggerben rá tudok nézni arra is, hogy pl. az IngyomBingyom az valóban egy olyan objektum-e, amire számítottam, nem-e, hogy egy másik osztály lett odapéldányosítva (mert mondjuk dinamikusan változhat bizonyos esetektől függően). Vagy van még egy csomó ötletem, amikor debuggerben egy pillanat alatt kijön, hogy hol a hiba ahelyett, hogy végigolvasnék n*1000 sornyi kódot.

Na, ha csak a kód olvasására bízod magad, akkor mindkét irányban nézheted meg, hogy merre lehet a hiba. (De gondolom, te architect vagy, te tökéletes kódot írsz, így elő nem fordulhat, hogy valahol hiba legyen...)

"a sajat fejlesztesrol van szo."

És csak te egyedül fejleszted, vagy mondjuk van még 8-10 másik ember munkája is a kódban? És nem használsz egyetlen létező külső libet, apit, akármit?

"prblakozas es kiserletezgetes"

Egyébként terveztél már GUI-t? Olyanba még nem futottál bele, hogy fejben úgy gondoltad, hogy valami jó lesz, aztán gyakorlatban mégse?

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Mi a kulonbseg? Ha ertem, hogy mit irtam le, akkor tudom, hogy hogyan mukodik, es forditva. Mit kell azon viszgalni?

- könnyen lehet egy nagyon triviális elírás (pl. == helyett =, a paraméterátadás csak érték szerinti, miközben a függvényben változtatod, stb.)
- matematikai elmélet megvalósításában (ha olyan függvényt csinálsz) két értéket véletlenül felcseréltél, esetleg egy "beépített" függvény nem úgy működik, ahogy "gondolod" (pl. a cos fgv paraméterét elfelejted radiánba átváltani)
- esetleg a fenti két esetben vázolt függvényt használsz egy olyan függvényben, amely jól működne, ha a hívott függvények jól működnének
- ld. saxus
- stb.

"Elméletileg az elmélet és a gyakorlat között nincs különbség. Gyakorlatilag van."