Čistý kód – zápisky

• Skautské pravidlo – po úpravách zanecháme kód čistší než byl (někdy stačí jenom přeformátovat, odstranit zbytečné komentáře, přejmenovat nelogické názvy, odstranit nepoužívané metody, rozdělit metody do více menších, apod.)
• DRY – don’t repeat yourself – žádný duplicitní kód (osobně se na tom vždycky vytrestám, protože upravím podobnou funkcionalitu jenom na jednom z dvou míst)
• Testy – musí být jednoduché, bez zbytečných podmínek, rychlé, aby to vývojáře nezdržovalo. Neříkejte si, že to otestujete později, neuděláte to. Pokud budete psát/vymýšlet testy před programováním, tak mohou pomoci při vývoji a návrhu aplikace, protože budete přemýšlet na výstupem, který budete testovat. Testujte i hraniční hodnoty. Testy nejsou samospasitelné, obvykle nepokrývají všechno.
• Smysluplná jména tříd, proměnných, metod – jména jsou výstižná, popisná a drží se i určitých konvencí, které už v systému existují (např. metoda pro vkládání do databáze se bude vždy jmenovat insertNěco() a ne addNěco()) Nepoužívají se proměnné typu X, Y, K, J. Výjimku tvoří cykly FOR, kde je to zažité. Nepoužívejte magické konstanty, i číslo 1 může mít svůj výnam (např. FIRST_DAY_OF_WEEK)
• Malý počet argumentů metod – max 3, pokud je jich hodně, tak je asi něco špatně a funkce lze rozdělit nebo dělá něco s daty jiných objektů, které by měli provádět operace se svými daty.
• Malé metody s jednou zodpovědností – metodu lze pochopit z názvu, pokud ne, tak při letmém pohledu do její definice (pokud jsou dobře pojmenované proměnné a funkce uvnitř) bez rolování. Metoda dělá právě jednu věc, proto pro ni snadno vymyslíme i výstižný název. Metoda nemá žádné vedlejší efekty. Metoda má návratovou hodnotu a nemění zbytečně data předávané v parametrech. Pokud do většiny metod předáváte stejný parametr, zamyslete se nad tím, jestli to nemá být proměnná/atribut objektu.
• Raději výjimky než chybové kódy – metoda typu validate() může vyhodit výjimku, pokud neprojde. Výjimka pak v sobě může obsahovat všechny chyby, které nejsou validní.
• Ideálně žádné komentáře – pokud je všechno dobře pojmenované, tak komentáře nejsou potřeba. Výjimkou jsou různé složitější algoritmy. Pokud je třeba komentář, tak co nejblíže ke komentovanému kódu. Nedělat zbytečně Javadoc komentáře, pokud to vyplývá z kódu samotného.
• Formátujte kód podle velkých používaných frameworků a používejte možností vašeho IDE, které se o to postará za vás
• Nepoužívejte objekty jenom jako skladiště společných metod. I takové skladiště musí mít nějaké společná data a logickou souvislost, aby opět plnila právě jednu zodpovědnost. (Špatným příkladem jsou třídy Utils, Tools někdy i System, kde se vyskytuje všechno, s čím nevíme, kam to patří.)
• Nepředávejte ani nevracejte hodnotu NULL, zbytečně ji pak budete muset testovat. Pokud se něco nepodaří, tak je to výjimka. (Sám toto pravidlo tak úplně nedodržuji)
• Jedna třída = jedna zodpovědnost, jedna metoda = jedna transformace dat/stavu
• Neprogramujte do zásoby – pokud nevytváříte framework nebo nějakou knihovnu, která právě obsahuje metody, které volá až někdo další, tak nevytvářejte třídy a metody, které by se vám mohli v budoucnosti možná hodit.
• Smažte nepoužívaný kód, zbytečně znepřehleďnuje.
• Zapouzdřete podmínky – přiřaďte složitější podmínky do proměnných nebo na ně vytvořte metody
• Metody s jednou úrovní abstrakce – pokud v metodě načítáme seznam objednávek přes OrderTable a zároveň na stejném místě přímo zapisujeme do souboru pomocí write(), tak to možná značí něco o špatném návrhu

Zdroje:

MARTIN, Robert C. Čistý kód. Vyd. 1. Brno: Computer Press, 2009, 423 s. ISBN 978-80-251-2285-3.