Tiszta kódolás

„A kód mindig rohad” - Gémes Tamás
„Code are simple and direct like a prose” - Grady Booch

Általános alapvetések

Miért szükséges a tiszta kód? - kérdezhetjük. Egyszerű megközelítés: a fejlesztés idő, az idő pénz… De hol térül meg a befektetett idő, energia. A tiszta kód tanulható, csak eleinte jelent nehézséget és idővel rutinná válik. Ha ’smell’ kódot írunk, gyorsan lehet haladni, értjük is a saját magunk által megálmodott logikát, azonban, ha újra elővesszük a kódot, vagy másnak kell hozzányúlni (Code Legacy – Kód örökség), akkor fontos, hogy a pontos működést gyorsan megértsük és hozzá tudjunk fejleszteni. Grady Booch szerint úgy kell tudni olvasni, mint egy regényt. Nem szabad visszalapozni, egyértelműen sorról-sorra lehet értelmezni. Így a megértés és a hozzáírás fog lényegesen lerövidülni.

Duplikáció elkerülése

Ha már kétszer használunk kódot (számolást, visszatérést, megjelenést), saját függvényt, metódust írjunk. (Let DRY – Don’t Repeat Yourself). Egy megoldás csak egyszer implementáljunk. Ha redundánsan van jelen a kódban – let légyen az számítás, megjelenés, meghívás, stb., ha módosítani kell kényelmetlen és több hibázásra ad lehetőséget.

OCP

Open/Closed Principle – Legyen zárt a változtatásokra, de legyen nyitott a bővítésre. Egy új ’feature’ bevezetéséhez ne kelljen belenyúlni a régi kódba. Azonban a régi kódhoz tudnia kell kapcsolódni.

Code review

Csak abban az esetben, ha funkcionálisan megfelelően működik. Heti rendszerességgel a megírt kódokat közösen átvizsgáljuk. Így ki lehet szűrni a túlbonyolításokat, a code-smelleket, nem utolsó sorban tanulhatunk belőle, egymástól.

End-To-End felelősség

A kódért csoport felelősség van. Felel a tervező, a „designer”, a tesztelő, a kódoló és a manager is. Tervezéstől az üzemeltetésig. Ha ügyfél oldalról vizsgáljuk a felelősségi kérdést még inkább igaz ez – a cég a felelős. Ezért fontos, hogy a kódot mindenki magáénak érezze. Ha valaki ’out of project’ is ismerje, tegye bele a saját tudását. – visszacsatolva a Code review-ra

Kommentek

Kerüljük, ha csak lehet az öncélú kommentet („//” kerülése)… A saját, undeployed feladatoknál elfogadott. De távolítsuk el. Használjunk beszédesebb metódust, változó elnevezéseket. Később saját magunk sem emlékezünk rá mit is akartunk. Helyette saját (új) metódus bevezetése a célszerű.

// Check to see if the employee is eligible
// If full benefits
if(($employee->flags && $emloyee->age > 65) && $employee->dayOk)

helyett:

if ($employe->isEligibleForFullBenefits())

Hatékony is, mert elég a metódust updatelni és máris up-to-date a kódom. Azonban dolgozhatok duplán a kommentekkel, vagy rosszabb nem követem. A legnagyobb baj, ha „out-of-sync”-be kerülnek. Ezért code smell a comment is.

Elnevezések

Kerüljük a ’mental-mapping’-et.

$d = 7; //working day in the part of plant

helyett:

$plantWorkingDay = 7;

A mental-mapping egy belső térkép, szótár, amiből mi magunk tudjuk, hogy az adott változó (elnevezés) mögött milyen tartalom, funkció, eredmény van. Jobb esetben ezt kommenteljük, de a kód olvasásához nekünk is memorizálni kell - feleslegesen.

Elnevezés angolul (nyelvtani helyességgel), törekedve minél beszédesebb elnevezésre, csak az általánosan elfogadott rövidítések használatával (average = avg). De gondoljunk a szóbeli kommunikációra is, kiejthetőség elve és minél kevesebb legyen. Rossz példa:

getPmtCryByPmtId() : array