Elnevezések:

o kommunikálja jól a szándékot

o ne legyen félrevezető, bizonytalan jelentésű
o hosszabb elnevezések kis eltéréssel
o helyesírás
o kiejthető (az esetleges szóbeli kommunikáció miatt)
o típusra utalást NE
o probléma, megoldás domén elnevezések (account, JobQueue)
o ne mókázzunk (whack vs kill)
o class: főnév (kerüljük a túl általánost: pl. Manager, Info, Data)
o metódus: ige vagy igei alak
o adott koncepciót egységesen ugyanavval (retrieve, fetch, get)
o több koncepcióra ugyanazt ne
o elegendő kontextust kapjon (number: phone or people?)
o de többet ne
o ésszerűen minél rövidebb

Metódus:

o rövid
o részekre szedés
o követhető szerkezet
o kevés behúzási (indent) szint
o rövid sorok
o egy dolgot csináljon
o ugyanazon absztrakciós szinten maradjon (details vs essential concepts)
o The Stepdown rule – Lépésenkénti haladás
o argument: az ideális, ha nincs; háromnál több kétséges
o output argument: nehéz megérteni
o flag argument: ronda, jelzi, h nem egy dolgot csinál
o side effect: ne!
o command-query separation: vagy-vagy, ne mindkettőt
o exception: részesítsük előnyben a visszatérési értékkel szemben
o try-catch: a blokkok tartalma külön fgv
o hibakezelés: „egy dolog”
o enum hibatípus: dependency magnet
o DRY: don’t repeat yourself

Switch statement:

o veszélyes
o hosszú
o túl sokat csinálhat
o Open Closed Principle sérülhet
o -> Abstract Factory-ba rejtés

Komment: legtöbbször a szükséges rossz

o a nem pontos rosszabb, mint a hiányzó

o gyakran a rossz kódot próbálja kompenzálni
o jó:
o jogi
o informatív: pl. regexp magyarázata formátummal
o szándék magyarázata
o tisztázás (pl. a < b)
o következményekre figyelmeztetés
 o TODO
o megerősítés
o API doc!
o rossz:
o érthetetlen motyogás
o redundáns (a kód OK)
o félrevezető
o kötelező jelleggel letudott
o zaj (semmitmondó)
o függvény vagy változó helyett
o pozíció jelzés (forráson belüli szekcionálás)
o kiiktatott kód!túl sok infó
o API doc nem publikus kódra

Kódformázás

o függőleges:
o kisebb fájlokat általában könnyebb megérteni
o újság metafóra
o szellős vs tömör (térköz)
o távolság
o változó deklaráció: közel a felhasználáshoz
o példányváltozó: az osztály tetején
o függő metódusok
o koncepcionális affinitás (az összetartozó részel közelsége)
o rendezés
o vízszintes
o a rövidebb jobb (a technológia megengedne hosszút is..)
o szellős vs tömör (térköz)
o alignment
o indent
o konvenció -> egyezség!

Objektumok és adatstruktúrák

o objektum:
o absztrakció: megvalósítás elrejtése
o adatreprezentáció
o adatmanipuláló függvények
o adatstruktúra
o adatok feltárása
o nincsenek adatmanipuláló függvények
o Demeter törvénye: egy modulnak nem szabad tudnia az általa manipulált objektumok
belsejéről (a.getB().getC() )
o hibrid: kerülendő
o a.getC() vs a.doSomethingOnC()

Hibakezelés

o fontos
o ne zavarja a programlogikát
o lsd metódus
o checked vs unchecked: pros vs cons
o Special Case Pattern
o return no null: SCP, NullObject Pattern etc

Határvonalak
 o 3rd party kód: korlátozzuk/csomagoljuk be
o felfedező tesztesetek (ne a kódban)
o nem kiforrott elképzelések IF mögé rejtése
o világos definíció

Unit teszt

o TDD három törvénye -> rengeteg kód, tiszta!!

o először hibázó teszt kód, utána a tesztelendő kód
o csak annyi teszt kódot szabad írni, amennyi elegendő egy hibára; a fordítási hiba is
hiba
o csak annyi tesztelendő kódot szabad írni, amennyi a hibázó tesztet megjavítja
o test enable –ilities
o olvashatóság
o domain-specific test language
o hatékonyság nem szempont
o assert/teszt (TDD) vs 1 koncepció/teszt
o FIRST: fast, independent, repeatable, self-validating, timely

Class

o elrejtés
o kicsi
o egyetlen felelősség (Single Responsibility Principle)
o kohézió: példányváltózók száma vs az egyes metódusok által használtak száma
o a fentiből -> sok kis osztály
o változásra tervezés
o változástól elhatárolás: DIP

Rendszerek

o „Complexity kills. It sucks the life out of developers, it makes products difficult to plan, build,
and test”
o a rendszer konstruálásának és futásának szétválasztása
o lusta inicializálás
o factories
o DI (ellentmondásos)
o separation of concerns
o cross-cutting concerns: AOP, Java Proxy
o döntés optimalizálás: ki, mikor
o standardok: demonstrálható értéket adjanak
o DSL!!!

Emergence (kialakulás)

o Simple Design
o minden teszt futtatása
o nincs duplikáció
o kifejezi a programozó szándékát
o class/method száma minimalizált
o 2-4: refaktorálás!

Többszálúság

o nehéz és komplex
o „mit” „mikor” szétválasztása
 o nem mindig teljesítménynövelő
o rendszerint mély hatással van a rendszer struktúrájára
o a konténerek sem mentenek meg tőle
o bonyolítja a kódot
o hibák nehezen felderíthetők
o stb.

Gyanús kód (code smell - Martin Fowler)

o rossz kommentek
o környezet:
o egyetlen lépésben végre nem hajtható build
o egyetlen lépésben végre nem hajtható teszt
o lsd. metódus problémák
o általános
o egyetlen forrásfájlban több nyelv
o nyilvánvaló viselkedés nem implementált
o nem korrekt viselkedés határvonalon: minden eset lefedése
o felülírt biztonsági pontok (pl. nem működő teszteset kiiktatása)
o DRY megsértése
o hibás absztrakciós szintű kód
o ősosztály függése a leszármazottól
o túl sok információ (modul API)
o zűrzavar, döglött kód
o nagy függőleges szeparáció
o inkonzisztencia (kövesd a konvenciókat)
o mesterséges (szükségtelen?) csatolás
o funkció-irígység (Demeter?)
o selector argument (flag argument)
o homályos szándék
o rosszul elhelyezett felelősség
o alkalmatlan static
o nem érthető algoritmus (tesztek lefutása nem elég)
o if/else, switch/case
o elnevezés nélküli mágikus konstans
o precizitás hiánya
o a struktúra megelőzi a konvenciót
o feltételes szerkezet elrejtése
o negatív feltétel
o rejtett időbeli csatolás
o önkényesség