Objektumorientált szoftvertervezés - 4. előadás
Clean code¶

Mi a clean code?¶

rossz kód: nehéz olvasni, megérteni, karbantartani
- hátránya: csökkenti a produktivitást
kódot többet olvassuk mint írjuk
tulajdonságok: könnyű olvasni, megérteni, elegáns, hatékony, minden hibát kezel, könnyen lehet dolgozni vele

az osztálynevek főnév jellegűek legyenek (ige max Visitor vagy Strategy minta esetén legyen)
a függvénynevek ige jellegűek legyenek
használjuk az alkalmazási terület elnevezéseit
használjunk beszédes neveket
változó nevébe kódoljuk a jelentését és mértékegységét is (elapsedTimeInDay)
kerüljük a félreinformálás
használjunk megkülönböztető neveket
használjunk kimondható neveket
használjunk kereshető neveket
kerüljük a névkódolást
használjuk a hatókörnek megfelelő hosszúságú nevet
adott dologra mindig ugyanazt a nevet használjuk
biztosítsunk értelmes kontextust (hogy egyértelmű legyen a név jelentése)
hagyjuk el az értelmetlen kontextust (pl prefixeket hagyjuk)

a függvények legyenek kicsik (2-4sor)
a blokkok belseje egyetlen sor legyen (különben külön fv legyen, blokkok ne legyenek egymásba ágyazva)
egy függvény egyszerre csak egy dolgot csináljon
egy függvény egyszerre csak egy absztrakciós szinten dolgozzon
a függvények lépcsőzetesen kövessék egymást (az absztrakciós szinteket folyamatosan kibontva)
egy függvénynek minél kevesebb paramétere legyen (0-1-2)
kerüljük a mellékhatásokat (erre nem számít a hívó!)
válasszuk szét a parancs és a lekérdezés jellegű függvényeket

motyogás (tartalmatlan információ)
redundáns komment (olyan komment, ami a kódból is kiolvasható)
kötelező kommentek (ha kötelező mindent kommentelni :( szóval ezt ne tegyük kötelezővé!)
idegességből hagyott komment
komment függvény vagy változó helyett (inkább kifejező kódot írjunk!)
feltűnő banner jellegű kommentek (/---------------------/ na ilyet ne)
blokkzáró kommentek (itt a while vége)
kikommentezett kód (ilyet se hagyjunk, csak gyűlni fognak! használjunk verziókövetést)
napló jellegű komment (helyette verziókövető rendszert használjunk)
szerzőt hitelesítő komment (szintén verziókövetővel pótoljuk)
HTML kommentek (dokumentációgenerátor csinálja inkább)
nemlokális információ (inkább hivatkozzuk az adott helyet)
túl sok információ (ne teljes szabványt másoljunk be!)
hiányzó kapcsolat (legyen nyilvánvaló a kapcsolat)

informatív kommentek
szándék illetve tervezői döntés magyarázata (ez fontos!)
bonyolultabb szintaxissal rendelkező kódot magyaráznak (ne felejtsük őket szinkronizálni)
figyelmeztetés a következményekre (pl valami nem szálbiztos)
TODO kommentek
hangsúlyozó kommentek (mit ne töröljünk ki)
publikus API dokumentálása (sokmindent szépen írjunk bele!)

hibakódok helyett használjunk kivételeket (alkalmazáslogika külön függvénybe)
biztosítsunk kontextust a kivételhez (hol keletkezett, miért, hogy elkerülhető)
használjunk unchecked (runtime) kivételeket (ne hárítsuk a kliensre a lekezelést)
a kivételeket mindig a hívó szemszögéből definiáljuk (ne kényszerítsük, hogy a kliens megértse mi van a szervernél)
ne térjünk vissza null értékkel (dobjunk kivételt, vagy NullObject tervezési mintát használjunk)
ne adjunk át paraméterként null értéket

Procedurális kód	Objektumorientált kód
fókuszba: adat	fókuszban: viselkedés
viselkedés külön függvényekben	adatreprezentáció elrejtve
könnyű új függvényt adni az adatstruktúra változtatása nélkül	könnyű megváltoztatni a belső adatreprezentációt a külső interfész megváltoztatása nélkül
nehéz megváltoztatni az adatstruktúrát, mert az minden függvényre hatással lehet	nehéz megváltoztatni a külső interfészt, mert az minden hívóra és leszármazottra hatással lehet
stabil viselkedés: ORM, DTO	stabil viselkedés: OCP