Hogyan írjunk jó kódot?

Ahhoz, hogy jó kódot tudjunk írni, először tisztáznunk kell a jó kód fogalmát. Ezt sokan sokféleképp definiálták a témához kapcsolódó számos szakirodalomban. Véleményem szerint a jó kód könnyen érthető és akár évekkel később is könnyen bővíthető, karbantartható. Ez egyszerűen hangzik, azonban a gyakorlatban igen nehéz megvalósítani.

Éppen ezért ez a fejezet leginkább vázlatpontokba szervezett tanácsok, ajánlások gyűjteménye lesz, hogy mit érdemes és mit nem érdemes csinálni.

Használjunk beszédes neveket

Minél beszédesebb a változó, metódus vagy osztály neve, annál könnyebb kitalálni később, hogy az adott kódrészlet mit is csinál és valójában mire is gondolt a költő.

Bontsuk részegységekre a programot

Az igazán olvashatatlan kód ismertető jele, hogy tele van nagyméretű metódusokkal. Igyekezzünk úgy szervezni a kódunkat, hogy kicsi, kompakt metódusokból és osztályokból álljon. A kis méret igen relatív. Egyes ajánlások szerint ez maximum 10-15 sor metódusonként. Személy szerint én valahol a határt 50 sor környékén húznám meg. Osztály bontás esetén egy osztály csak egy valamiért feleljen.

Csak azt kommentáljuk, amit kell

Dokumentációt írni egy programozó sem szeret. A jó kód elmagyarázza magát. Egyértelmű dolgokat ne kommentáljunk. Ha a metódusunk neve például KedvezmenytSzamolUgyfelnek akkor felesleges megkommentálni, hogy a metódus kedvezményt számol egy ügyfélnek, mert a nevéből kiderül.

Azonban ha a kódban van egy nem triviális számítás, képlet, vagy egy magától nem érthető részlet, akkor azt érdemes részletesen kommentálni.

Ne találjuk fel újra a kereket, éljünk a keretrendszer lehetőségeivel

A keretrendszer, amit használunk a nyelv mellé, profik által lett tervezve. Okkal tettek rendező metódust a lista kollekcióba. Nyugodtan használjuk, nem kell feltalálni a saját módszerünket. Sok esetben csak ártani fogunk a sebességnek a saját megoldásokkal.

Más kódja csak ihlet legyen

Amióta StackOverflow van, azóta a problémamegoldás lényegesen egyszerűbb, mert nagy valószínűséggel már valaki találkozott a problémánkkal. Ezeket a kódokat azonban csak ihlet forrásként kezeljük. Ezáltal fejlődünk és a kódrészlet nem fog drámaian elütni a többi kód stílusától.

A kivételkezelés nem programlogika szervezésre való

A try - catch utasítás páros lényegében egy kultúrált goto utasítás hiba esetén. Ennek az ugrásnak igen nagy sebesség költsége van. Éppen ezért programlogikát ne építsünk vele. Erre valóak az if - else és a switch - case vezérlési szerkezetek.

Kerüljük a Pokémon stílusú kivételkezelést

Ha a catch blokkunk minden típusú hibát elkap, akkor beszélünk Pokémon stílusú kivételkezelésről¹. Ez azért nem jó módszer, mert kritikus, nem tervezett hibák elnyelődhetnek, ami később nagyon megnehezíti a hibakezelést. Éppen ezért a Pokémon stílusú kivétlekező csak a legvégső kivétel kezelő vonal legyen.

Ne legyen üres kivételkezelő blokkunk

Ha a try-catch szerkezettel körbevédünk egy kódrészletet, és a kivétel elkapás egy üres blokk, az sok fejfájást fog okozni a későbbiekben. Leginkább azért, mert a "kezelt" kivételről nem szerzünk tudomást, illetve az ilyen blokkok a leggyakrabban tervezési hiba eredményei. Ha egy hibát csendben szeretnénk kezelni, akkor legalább naplózzuk, vagy kommentáljuk meg a kivételkezelőt, hogy miért maradt üresen.

Ne legyen a kódban Magic Number

A Magic number kifejezést akkor szokás használni, ha egy algoritmus tele van olyan beégetett számokkal, amelyek jelentése nincs definiálva a kódban. Például:

int a = 0.5 * b * 0.2 * c;

Sehogy nem derül ki, hogy a 0.5 és 0.2 szorzóra a fenti kontextusban mi szükség van, illetve mi a céljuk. A kód olvashatóságán drámaian javít, ha az ilyen értékeket egy külön osztályba konstans változókként kiszervezzük és onnan hivatkozunk rájuk, vagy egy enum típusban felsoroljuk őket. A konstansokba szervezés a későbbi karbantarthatóságot is növeli. Több helyen is szerepelhet egy magic number – ha meg kell változtatni, jobb ha csak egy helyen kell.

var típust csak ésszel használjunk

A var típus a C# egyik legnagyobb erőssége, de ennek is megvannak a kockázatai. Nézzünk egy példát erre:

var x = CsinaljValamiSzamitast();

A metódus nevéből nem derül ki egyértelműen, hogy milyen típust ad vissza, így olvasás közben nem lehet megmondani, mi lesz x változó típusa. Éppen ezért var típust csak akkor használjunk, ha a kifejezés jobb oldalából egyértelműen beazonosítható a típus.

dynamic csak akkor, ha tényleg kell

A dynamic típus a szkriptnyelvekkel való együttműködés miatt került be a nyelvbe. Csak akkor használjuk, ha szükségünk van rá, mert jelentős performancia degradációval jár, valamint a használata során nem működik a futásidejű típusellenőrzés.

Tags Clean, Code, Írás, Jó, Kód, Tanácsok