2018. december 12.

Halott kód, eleven problémák

10 perc olvasási idő

Halott kód, eleven problémák

A Wikipedia szerint a halott kód a forráskód olyan része, ami lefut, viszont az eredménye soha nem lesz felhasználva a program további futása során. A halott kód futtatása felesleges memóriát és processzoridőt igényel. Ezzel maximálisan egyetérve, úgy érzem még kibővíthető a kör a kikommentezett kódrészekre továbbá a soha nem hivatkozott metódusokra. Az előzőek processzort és memóriát ugyan nem vonnak el a többi folyamattól, azonban jócskán megzavarhatják a fejlesztők munkáját. Vegyünk pár tipikus esetet:

1. A feleslegesen lefutott műveletek

A szoftverfejlesztés hőskorában néhány kilobyte memóriában el kellett férnie a programnak, mivel egyszerűen nem volt több hely. Ha manapság kevés az erőforrás (web esetén legalábbis), jellemzően a rendszergazdánál kötünk ki, hogy emelje meg a memórialimitet vagy a maximális futási időkorlátot. Személy szerint azért szeretek Arduinoval játszadozni, hiszen ott még figyelni kell a memóriahasználatra és nem létezik a végtelen erőforrás illúziója.

Minden feleslegesen letudott kódsor, vagy indokolatlanul deklarált változó felesleges erőforrásokat von el futás közben, és bizony még mapanság is könnyen futhatunk olyan projektbe, ahol minden byte számít.

A rossz hír az, hogy az ilyen kódrészeket automatizáltan elég macerás kiszűrni, viszont az átgondolt tervezés, fejlesztés és a refaktorálás könnyen megoldja a problémát.

2. Soha meg nem hívott metódusok

Az megvan, amikor létezik egy osztályban getImages() és getImages2() függvény is? És, miután kikáromkodtad magad, további erőfeszítéseket okoz, hogy megtaláld, most végülis melyik is az éppen használatban lévő. Legacy kódban jellemző az ilyen
megoldás és noha kárt nem okoz, jelentősen elbizonytalaníthatja a fejlesztőt vagy éppen félreértésekhez vezethet a jelenléte.

Ide sorolhatóak azok a kódrészek is, amik egy mindig bekövetkező visszatérés vagy megszakítás után következnek, és gyakorlatilag soha nem ér el a folyamat oda, hogy lefussanak, továbbá az indokolatlanul, soha használatba nem vett változókról is érdemes megemlékezni.

Szerencsére, az ilyen problémák beazonosítása már sokkal jobban automatizálható, és létezik is hozzá kész eszköz, pl. a PHP Dead Code Detector (PHPDCD)

dead and unreachable code

3. Kikommentezett kódok

A legrosszabb dolog. Egyszerűen elkerülhető lenne, de mégis „kitudja, mikor kellhet még” alapon ott vannak a kikommentezett var_dump-ok, fél függvények, vagy rosszabb esetben teljes osztályok az újraírt kóddal közös forrásfájlban.

Természetesen létezik az az eset, amikor valamit ott hagyunk megfelelő magyarázattal, vagy neadj’isten debugolsz és véletlenül ott marad egy sor. Viszont az indokolatlanul otthagyott kódok sokasága esetén a szándékosság csak súlyosbító tényező, hiszen a verziókezelőben elérhető lesz törlés után is. A tapasztalat is az, hogy minimális az esélye, hogy újrafelhasználásra kerülnek az ilyen kódrészek.

Tartsd tisztán!

A halott kódok alapvetően megbonyolítják a mindennapi munkát, félreértésekhez vezethetnek és bizonytalanságot okoznak. Amikor csak lehet kerüld, és ne hagyj magad után felesleges kódot, ha használsz bármilyen verziókezelőt, nem tűnik el véglegesen semmi. Személy szerint azt gondolom, hogy a professzionalizmus egyik jele, hogy milyen szép kódot hagyunk magunk után, aminek egyik ismérve, hogy nincs tele haszontalan dolgokkal. Így hát csak bíztatni tudlak, hogy tarts rendet, takarítsd ki ha hasonlóval találkozol, legyen szó akár a saját, akár más kódjáról.

Tóth Zoltán

Vezető fejlesztő. Közel tíz éve foglalkozik webfejlesztéssel, igyekszik egyaránt backend és frontend területen is képben lenni. WordPresspárti, böngészőkiegészítő- és bookmarkletgyűjtő.

Tóth Zoltán

Hozzászólások