Mért nem jó, ha kommentet írunk egy kódhoz?

Az elso videoban a fo motivacio az hogy a programozasban nem szeretjuk a redundanciat, azaz azt amikor egy lokiga ket helyen is meg van irva. Ha irsz egy kommentet, ami egy bonyollultabb kodreszletet magyaraz, akkor a kommentben is meg van irva a logika meg a kodban is. Igy ugyan az a problema vele mint ha a kod lenne megirva ket helyen: elofordul, hogy atirod a kodot, de a kommentet nem, igy egy ido utan a komment mar nem azt fogja leirni amit a kod valoban csinal. Ezert a video azt javasolja, hogy probald meg ugy irni a kodot, hogy ne szoruljon az egy kommentre ami egy komplexebb logikat fejt ki.

A nested kodos videoval is egyet tudok erteni. Ott azt mondja, hogy ne legyen a kododban tul sok nesting (konkretan: 3nal tobb szint). Ezeknek a kodoknak a flow-jat nehez fejben tartani. Peldaul amikor egy adott kodreszletet szerkesztesz, es oda 5 if agon at jutsz, akkor ott eleg nehez fejben elkepzelni, hogy akkor mikor is jut oda a kod tulajdonkeppen. Az egyik legegyszerubb modja a tulzott nesting elkerulesenek, ahogy a video is mondja, ha a happy patht hagyod a kod vegere es a kod elejen kezeled a hibakat es kilepsz a fuggvenybol hiba eseten, a helyett hogy egy if agban lenne a hibakezeles es egy else agban a hibamentes flow.

Az optimális állapot az, ha egy kód ún. self-explanatory, azaz minden szempontból úgy van megírva és strukturálva, hogy könnyen érthető.

Ilyenkor elvileg nincs szükség arra, hogy kommenteld.

De természetesen ez egy olyan elmélet, ami tankönyvekben tök jól működik, a gyakorlatban viszont ez nem mindig megvalósítható, így aztán a valóságban van létjogosultsága a kommenteknek is.

De azért nem árt törekedni erre.

Sokat tudnék erről írni.

De nem fogok.

Ha kommentel kell magyaráznod valamit akkor az esetek többségében azt jelenti hogyha valaki leül a kódod elé akkor nem fogja átlátni, hogy mit csináltál. Márpedig nagy az esély rá hogy a jövőben valakinek módosítania kell.

Célszerű a változókat úgy elnevezni hogy tudjad hogy mi mit tartalmaz. Pl egy dictionary-t ha elnevezel "data" nak akkor az olvasónak foggalma sincs hogy mi van abban, helyette azt mondhatod hogy legyen username_by_name, máris meg tudod mondani hogy mik a kulcsok és mik az adatok.

A másik hogy a funkcióknak nem szabad túl komplexnek lenniük. Nem egyszer láttam 4 szintes if-elif eket kódban for ciklusokban. Egyszerűen követhetetlen hogy mi történik. Célszerű ilyenkor refaktorálni és kisebb funkciókba szedni a kódot, ahol maga a funkció név egyértelmű választ ad arra, hogy mit csinál.

Ami kivétel ezalól azok a speciális esetek. Ezek általában problémák amikre nem számít az ember, tipikus példa erre az adatbázisok ahol előfordulhat 1-1 hiba amit kezelned kell. Mondjuk kötelező oszlopok az esetek 99.9% ban ki vannak töltve de van 1 eset ami elhasaltatja a kódot ha nem kezelem, viszont ha valaki ránéz az adatbázisra akkor nem biztos hogy látni fogja ezt és lehet hogy kiszedné ezt a kezelést mert "értelmetlennek" tűnik

A JÓ komment mindig hasznos és kell is.

Használd, mert csak megkönnyíted vele a dolgodat (és esetleg másokét) a későbbiekben.