1. diel - Najčastejšie chyby programátorov - Vieš pomenovať premenné?

Vitajte pri prvom tutoriále kurzu Best practices pre návrh softwaru! Naučíme sa predchádzať častým chybám a navrhovať aplikácie tak, aby sa po čase nestali neprehľadnými a bolo ich možné ľahko rozširovať. V praxi sú aplikácie často veľmi rozsiahle a tieto znalosti sú úplne kľúčové na odvedenie dobrej práce. Práve umenie programovať správne robí z juniorov mediorov a seniorov a posúva vás na platovej škále dopredu.

Keďže si zakladáme na kvalite našich absolventov, nevyhnutné minimum z tohto kurzu je v podobe niekoľkých lekcií už obsiahnuté priamo v našich kurzoch programovania. Je teda možné, že ste sa s niektorými, najmä prvými časťami kurzu, už stretli. Ak áno, získate tu samozrejme ďalšiu porciu informácií, ktoré naštartujú vašu programátorskú kariéru a zabránia mnohým chybám, ktoré by ste inak mohli urobiť.

Slovo senior programátora

Materiál pre tento kurz som zostavil na základe 20-ročných skúseností s programovaním. Ako šéfredaktorovi a lektorovi mi rukami prešli stovky, možno tisíce zdrojových kódov vytvorených komunitou. Nebolo ťažké si všimnúť, že väčšina z nich, hoci funguje, obsahuje zbytočné chyby, ktoré sa navyše stále dookola opakujú. Chyby napodiv často robili nielen nováčikovia, ale aj skúsenejší programátori a aj ja som ich robil, keď som začínal.

Prišiel som k záveru, že základným a mylným predpokladom je:

✗ Program je správne, ak funguje.

Programy a domy

Keď staviame dom, že sa nám páči a že do neho nefúka, neznamená, že je správne postavený. Dom totiž musí mať premyslenú architektúru a ak nemá základy, o pár rokov sa nám začne zosúvať.

Programovanie je často prirovnávané k stavebníctvu práve kvôli architektúre, avšak tu sa jedná o tú softwarovú. Vysvetlime si prečo.

Ľudský mozog dokáže naraz pracovať len s určitým obmedzeným množstvom informácií. Zjednodušene môžeme povedať, že ak je program neprehľadne napísaný, od určitej chvíle by musel programátor udržať v hlave viac vecí, než vôbec dokáže. Pridávanie ďalších funkcií do takého programu potom vždy spôsobí, že v aplikácii vznikne chyba. V praxi to dopadá tak, že hobby projekt autora "prestane baviť" alebo komerčný projekt skrachuje, pretože je "už veľmi zložitý".

Uveďme si ešte iný príklad – keď bude naša domácnosť usporiadaná tak, že kladivo bude v lekárničke, ktorá bude umiestnená v pivnici, asi ťažko v nej budeme schopní efektívne fungovať. Hoci tento príklad znie absurdne, jeho alternatívy v podobe programov vznikajú denne.

Kedy je program správne?

To je ľahké. Program je správne, ak:

• funguje,
• dodržiava dobré praktiky a
• je otestovaný.

Všimnite si, že funkcionalita z pohľadu používateľa programu predstavuje len 1/3 kritérií kvality programu. Podobne ako funkčnosť domu z pohľadu bývajúceho predstavuje asi iba zlomok jeho reálnej kvality z hľadiska stavbariny.

Práve o porušovaní dobrých praktík a kvalite kódu sa budeme v tomto kurze baviť. Záleží nám na tom, aby ste boli naozaj dobrí a dokázali si poradiť aj s väčšími aplikáciami, v ktorých každá chyba nabobtná do nepríjemných rozmerov.

Ako správne pomenovávať premenné?

V dnešnej lekcii sa budeme zaoberať premennými. Hovorí sa, že 10 % času niečo programujeme a 90 % času pre to vymýšľame názov Ide samozrejme o zveličenie, ale vtip naráža na nutnosť stráviť určitý čas vymýšľaním názvov premenných. To aby každý vo vývojovom tíme vrátane nás, vracajúcich sa po pár mesiacoch k vlastnému kódu, pochopil, na čo daná premenná slúži. Všeobecne sa dá spoľahnúť na jednoduché pravidlo:

Premenné vždy pomenovávame podľa toho, čo obsahujú, nie podľa toho, na čo v programe slúžia.

Porovnajme nasledujúce 2 kódy:

Oba kódy vytvárajú premenné pre jednoduchý konzolový kvíz. V prvom príklade nie je vôbec jasné, čo niektoré premenné obsahujú, napr. pomenovať pole arr má asi rovnakú výpovednú hodnotu, ako by sme ho pomenovali variable.

Častou chybou je, že chceme napr. uložiť výsledok nejakého výpočtu a premennú pomenujeme calculation. Výpočet s premennou však vôbec nesúvisí, to je nejaká akcia (dej), premenná obsahuje vždy hodnotu (výsledok deja). Tou je v prípade kvízu totalBonus (alebo total_bonus, oddeľovanie slov záleží na konvenciách daného programovacieho jazyka, viď ďalej). Podobne je v prvom kóde premenná pomenovaná output, pretože ju niekde vypisujeme. Z druhého kódu ale reálne vidíme, že obsahuje názov kvízu.

Ruku na srdce - kto z vás by pochopil, že prvý kód sa týka programu na kvízy?

Tiež nikdy nepomenovávame pomocné premenné temporary alebo temp.

Pozor na mixovanie jazykov a diakritiku

Na úrovni začiatočníkov je prehľadnejšie pomenovávať premenné po slovensky. V praxi sa však stretnete takmer vždy s anglicky písaným kódom, preto aj naše pokročilejšie kurzy obsahujú identifikátory pomenované po anglicky.

Premenné v jednom projekte pomenovávame jedným jazykom, ideálne po anglicky. Ak ich pomenujeme po slovensky, tak bez diakritiky!

Opäť si ukážme príklady:

V identifikátoroch (napr. v názvoch premenných) nikdy nepoužívame mäkčene a dĺžne. V hodnotách v nich uložených je to už samozrejme v poriadku.

Napriek tomu, že moderné jazyky podporujú kódovanie UTF-8 aj v identifikátoroch, na mäkčeň a dĺžeň možno veľmi ľahko zabudnúť a potom tak používame inú premennú! Navyše súbor so zdrojovým kódom môže spracovávať aplikácia, ktorá ho nepodporuje, a typicky sa to aj časom stane (napr. je občas problém zobraziť mailovým klientom diakritiku v prílohe a pod.).

Viacslovné premenné

Dnešné aplikácie sú čoraz zložitejšie. Často sa stane, že jedno slovo nestačí na opis toho, čo je v premennej uložené. Potom je výhodné použiť viac slov. Krátke identifikátory z 80. rokov tak v súčasných business aplikáciách striedajú aj pomerne dlhé názvy ako userObjectOutputStreamFactory a podobne.

Takýto dlhý názov má však zmysel iba v zložitej aplikácii, kde je niekoľko podobných premenných a preto musíme pridať ďalšie slovo. Nebudeme teda v Hello world aplikácii vytvárať premennú textWithGreetingHelloWorld, ale stačí nám tam len greeting, ak tam iný pozdrav nie je

Oddelenie slov

Kvôli čitateľnosti slová v takom názve premennej musíme nejako oddeliť:

• Viac slov oddeľujeme podľa konvencie daného programovacieho jazyka. V Jave/C#/JS je to tzv. camelCase (slovensky ťavia notácia, kedy každé ďalšie slovo má veľké písmeno a názov potom vyzerá ako hrby). V jazykoch ako je Python/C sa používa podčiarknutie ako snake_case (pre triedy sa v Pythone používa PascalCase, viď ďalej v kurze).
• Vyhneme sa, pokiaľ možno, číslovaniu premenných a už vôbec nepíšeme čísla slovami, nie greet2 ani greetTwo. Two totiž nič nehovorí o tom, čo pozdrav obsahuje.

Ukážme si to na príkladoch:

Nepoužívame skratky

Túto podkapitolu začnime citáciou:

Všetci si lámali hlavu, k čomu je ten stĺpec DATBIR. Až sa raz zistilo, že je to vraj dátum narodenia (date of birth).

Táto zlá praktika je vlastne opakom viacslovných názvov premenných. Nevymýšľame nezmyselné skratky, napríklad z názvu rm nikto nespozná, že myslíme receivedMessage. Pomôcka môže byť:

Keď sa na kód pozrie niekto iný ako my, mal by presne vedieť, čo v ktorej premennej je.

V budúcej lekcii, Najčastejšie chyby programátorov - Vieš pomenovať objekty?, si ukážeme najčastejšie chyby začiatočníkov pri pomenovávaní tried, metód a atribútov.