Vaba mikrofon 1: Clean code

 Clean code ehk kuidas kirjutada koodi, mis on kergesti hallatav ja loetav ning arusaadav ka teistele arendajatele. Antud teema on kindlasti kogenumatele arendajatele hästi tuttav, kuid algajana on mulle pigem teada vaid üksikud fragmendid, seega mõtlesin, et oleks hea võimalus üht-teist juurde õppida, kokku võtta ja kirja panna. Üks tuntumaid raamatuid, mis antud teemast kirjutatud, on Robert C. Martini "Clean Code - A Handbook of Agile Software Craftmanship".

Mõned põhitõed võiksid olla järgnevad:

Kasuta tähenduslikke ja kirjeldavaid nimetusi

Klassi, funktsiooni, muutuja jm nimetus peaks muutma arusaadavaks, miks see eksisteerib, mida see teeb ja kuidas seda kasutatakse. Kui nimetus vajab kommentaari, siis järelikult on see halvasti valitud. Kindlasti ei tohiks nimetus sisaldada valeinformatsiooni, näiteks kui muutuja on "accountList", siis peaks see ka reaalselt olema List. Kui see seda ei ole, siis parem oleks kasutada mingit muud nimetust, näiteks "accountGroup" või lihtsalt "accounts". Kui mõni tsükkel on lühike ja kasutusel vaid ühes kohas, siis teatud üksikjuhtudel võib ühetäheline muutuja olla vastuvõetav, kuna see on levinud kasutusviis. Üldiselt on need siiski ebasoovitavad, sest lisaks muule on neid muutujaid ka koodist raske üles otsida.

Kasuta nimelisi konstante maagiliste numbrite asemel

Maagilised numbrid on numbrid, mis ei ole konstantidena defineeritud, seega ei ole võimalik peale vaadates aru saada, kust need sinna (maagiliselt) ilmunud on, ja mida need tähendavad. Näiteks arvu 0.22 puhul võiks ju miskit aimata, et küllap on käibemaksuga, kuid samas eeldab see siiski konteksti teadmist ning ei ole koheselt hoomatav. Parem variant oleks defineerida konstant: vat_rate = 0.22;

Funktsioonid peaksid olema väikesed ja tegema ainult ühte asja korraga

Funktsioonil peaks olema ainult üks ülesanne ja see peaks seda tegema efektiivselt. See teeb need arusaadavamaks ja ka paremini testitavaks. Samuti võiksid need sisaldada ainult ühte abstraktsiooni taset, ehk siis parem oleks mitte välja kutsuda segamini kõrgema taseme funktsioone (nt getHtml()) ja madalama taseme omi (.append("\n")). Funktsioonil ei tohiks olla ka liiga palju argumente - kõige parem 0 või 1 ja ainult väga hea põhjendusega rohkem kui 3.

Ära korda ennast

DRY ehk do not repeat yourself on väga levinud nõuanne ning enamasti on mõeldud seda, et ei tohiks olla erinevaid funktsioone, mis teevad sisuliselt samu asju. Nagu igal reeglil, on ka sellel erandeid. Teistes allikates võib aegajalt näha ka nõuandeid, et aegajalt võib kordamine olla siiski eelistatud sellele, et kood on liialt omavahel põimunud, nii, et muudatuste tegemine muutub keerulisemaks.

Kommentaarid ei paranda halba koodi

Tihti on näha, et kommentaare kasutatakse segase koodi selgitamiseks. Kui tekib tunne, et koodi peab selgitama, siis pigem tuleks kulutada aeg, et seda parandada, mitte selle asemel kommentaari lisada. On siiski mõned olukorrad, kus kommentaarid võivad olla asjakohased - näiteks selgitamaks, miks on midagi nii tehtud, nagu see on, hoiatused mingi tagajärje osas või TODO kommentaarid.

Need olekski minu arvates põhilised juhised algajale programmeerijale. Raamat iseenesest on väga põnev lugemine ja ladusalt kirjutatud, seega kindlasti tasub see ka täies mahus läbi lugeda, sest kõike siia pisikesse postitusse kindlasti ära ei mahuta.

Robert C. Martin "Clean Code - A Handbook of Agile Software Craftmanship"

https://blog.codacy.com/what-is-clean-code

https://programmingisterrible.com/post/139222674273/write-code-that-is-easy-to-delete-not-easy-to