( asch | 2019. 10. 24., cs – 09:31 )

Az igazán jó programozók tudják, hogy ezeknek a szabályoknak mi az eredete, és mikor lehet áthágni őket. Mikor van fontosabb egyéb szempont?

Az igazán jó programozók talán távolról követik az új divatokat, de nem ugornak bele fejest gondolkodás nélkül. És főleg nem várják azt, hogy egy új eszköz majd minden problémájukat meg fogja oldani. Nem fogja.

Néhány szabály:

* A programozás során a legszűkebb keresztmetszet az emberi felfogóképesség. Ezért az egyszerűségre kell törekedni, arra hogy a lehető legkevesebb dolgot kelljen egyszerre fejben tartani.
* Ha egy konstanst csak egyszer használsz, akkor _NE_ emeld ki konstans változóba! Növeli a sorok számát, és plusz egy indirekció, ami feleslegesen bonyolítja az értelmezést! Ha elfelejted, hogy már használtad egyszer, akkor legközelebb használva úgyis újradefiniálnád más néven.
* DRY - Don't Repeat Yourself! Írd le százszor, mert ez a legfontosabb!
* Ha egy mintát többször használsz, akkor nézd meg, hogy lehet-e általánosítani és kiemelni függvénybe vagy makróba!
* Amit lehet egy repóba tegyél, és kerüld a külön verziózást! Amit lehet kezelj belső API-ként, amikre nem vonatkozik a nehezen változtathatóság és a visszafelé kompatibilitás őrzése!
* Belső API-kon nem kötelező a mezők setter/getterbe rejtése: felesleges sorokat generál, és ha szükség lesz rá, akkor az IDE megcsinálja a bekapszulázást. A hasonló formára vonatkozó szabályokat is kezeld lazán, ha úgy látod helyesnek!
* Amit lehet - a külső függőségeid közül is - forrásként importáld az IDE-be. Az API dokumentáció sosem lesz olyan pontos, mint a forráskód, időnként nem árt beledebuggolni, beleolvasni a könyvtárakba is.

Gyakorláshoz módszerek: mivel az emberi felfogóképesség a szűk keresztmetszet, ezért ezt kell fejleszteni. Különösképpen a munkamemóriát!

* Nemtriviális méretű programot írj meg IDE támogatás nélkül parancssori fordítóval! Mivel nehézkesek a körbefordulások, illetve a keresés, ezért javítja a koncentrálóképességet és a memóriát!
* Írj nemtriviális programot papíron úgy, hogy arra törekedj, hogy begépelve egyből működjön!
* Nemtriviális programot debuggolj kizárólag trace üzenetekkel, debugger nélkül!
* Nemtriviális valósidejű programot debuggolj oszcilloszkóppal! Csinálj hozzá szimulátort!
* Írj programot (legalább programrészt) assembler nyelven!

Nem ezek a legfontosabbak, csak éppen ezek jutottak eszembe. És ezek az ellentmondásosak, amik vihart generálhatnak jó esetben :-)