Lekce 9 - Nejčastější chyby C# začátečníků - Umíš pojmenovat proměnné?
V předešlém cvičení, Řešené úlohy k 7.-8. lekci C# .NET, jsme si procvičili nabyté zkušenosti z předchozích lekcí.
V dnešním C# .NET tutoriálu si ukážeme první tzv. dobré praktiky pro programování v C# .NET. Často je porušují nejen nováčci a programátoři tak zanášejí do svých programů zbytečné chyby. Neděláš je také?
Slovo senior programátora
Gratuluji ke zdolání prvních lekcí Základních konstrukcí jazyka C# .NET!
Materiál pro dnešní lekci jsem sestavil na základě dvaceti let zkušeností s programováním. Jako šéfredaktorovi a lektorovi mi rukama prošly stovky, možná tisíce zdrojových kódů vytvořených komunitou. Nebylo těžké si všimnout, že ačkoli většina těchto kódů funguje, obsahuje zbytečné chyby, které se navíc stále dokola opakují. Chyby kupodivu často dělali jak nováčci, tak zkušenější programátoři. Mezi chybující jsem v začátcích patřil i já.
Došel jsem k tomu, že základním a mylným předpokladem je:
✗ Program je správně, pokud funguje.
Programy a domy
Pokud stavíme dům, tak to, že se nám líbí a nefouká do něj, neznamená, že je zkonstruovaný správně. Dům totiž musí mít promyšlenou architekturu, a pokud nemá základy, za pár let se nám začne sesouvat.
Programování je často přirovnáváno ke stavebnictví právě s ohledem na architekturu, v našem případě ovšem tu softwarovou. Vysvětleme si proč.
Lidský mozek dokáže najednou pracovat jen s určitým omezeným množstvím informací. Zjednodušeně můžeme říci, že pokud je program napsaný nepřehledně, od určité chvíle musel programátor udržet v hlavě více věcí, než člověk vůbec dokáže. Přidávání dalších funkcí do takového programu pak vždy způsobí, že v aplikaci vznikne chyba. V praxi to dopadá tak, že hobby projekt autora "přestane bavit" a komerční projekt zkrachuje, protože už je "moc složitý".
Uveďme si ještě jiný příklad. Když bude naše domácnost uspořádaná tak, že kladivo bude v lékárničce, která bude umístěna ve sklepě, asi těžko s ní budeme schopní efektivně fungovat. Ačkoli tento příklad zní absurdně, jeho alternativy v podobě programů vznikají denně.
Kdy je program správně?
To je snadné. Program je správně, pokud:
- funguje,
- dodržuje dobré praktiky a
- je otestovaný.
Všimněme si, že funkcionalita z pohledu uživatele programu představuje jen 1/3 kritérií kvality programu. Podobně jako funkčnost domu z pohledu bydlícího představuje asi jen zlomek jeho reálné kvality z hlediska stavařiny.
Právě o porušování dobrých praktik a o kvalitě kódu se dnes budeme bavit. Záleží nám na tom, abyste byli opravdu dobří, proto těchto lekcí naleznete napříč našimi kurzy vícero.
Jak správně pojmenovávat proměnné?
Říká se, že 10 % času něco programujeme a 90 % času pro to vymýšlíme název Jedná se samozřejmě o nadsázku, nicméně vtip naráží na nutnost strávit určitý čas vymýšlením názvů proměnných. To aby každý včetně nás, kdo se po pár měsících vrací k vlastnímu kódu, pochopil, k čemu ona proměnná slouží. Obecně se dá spolehnout na jednoduché pravidlo:
Proměnné vždy pojmenováváme podle toho, co obsahují, nikoli podle toho, k čemu v programu slouží.
Porovnejme následující 2 kódy:
✗ Špatně
string vypis, text2; int[5] pole; int foo, bar, x, vypocet;
✓ Správně
string nazev, jmeno; int[5] odpovedi; int i, j, bonus, celkovyBonus;
Oba kódy vytvářejí proměnné pro jednoduchý konzolový kvíz. U
prvního příkladu není vůbec jasné, co některé proměnné obsahují,
např. pojmenovat proměnnou pole
má asi stejnou vypovídací
hodnotu, jako kdybychom ji pojmenovali promenna
.
Častou chybou také je, že chceme např. uložit výsledek
nějakého výpočtu a proměnnou pojmenujeme
vypocet
. Výpočet s proměnnou ovšem vůbec nesouvisí, to je
nějaká akce (děj), proměnná vždy obsahuje
hodnotu (výsledek děje). Tou je zde v případě kvízu
celkovyBonus
. Podobně je v prvním kódu pojmenovaná proměnná
vypis
, protože ji někde vypisujeme. Z druhého kódu ale reálně
vidíme, že obsahuje název kvízu.
Ruku na srdce – kdo z vás by pochopil, že kód vlevo se týká programu na kvízy?
Také nikdy nepojmenováváme proměnné pomocna
nebo pom
apod.
Pozor na "czenglish" a diakritiku
Ve zdrojovém kódu je na naší úrovni začátečníků jedno, jakým jazykem budeme proměnné pojmenovávat (pokud tedy nepošleme Angličanovi kód v češtině).
Proměnné v jednom projektu pojmenováváme jedním jazykem. Pokud pojmenováváme česky, tak bez diakritiky!
Opět si ukažme příklady:
✗ Špatně
string zpráva = "Čau!"; int count;
✓ Správně
string zprava = "Čau!"; int pocet;
Nebo:
string message = "Čau!"; int count;
V identifikátorech (např. v názvech proměnných) nikdy nepoužíváme háčky ani čárky. V hodnotách v nich uložených je to již samozřejmě v pořádku.
Přestože moderní jazyky podporují kódování UTF-8 i v identifikátorech, lze velmi snadno na háček nebo čárku zapomenout a používáme pak jinou proměnnou! Navíc soubor se zdrojovým kódem může zpracovávat aplikace, která jej nepodporuje, což se typicky i časem stane (např. je občas problém zobrazit diakritiku v příloze mailovým klientem apod.).
Víceslovné proměnné
Dnešní aplikace jsou stále složitější. Často se stane, že by jedno
slovo k popisu toho, co je v proměnné uloženo, nestačilo. Pak je výhodné
použít více slov. Krátké identifikátory z 80. let tak v současných
business aplikacích střídají i poměrně dlouhé názvy jako
userObjectOutputStreamFactory
a podobně.
Takto dlouhý název má ovšem smysl jen ve složité
aplikaci, kde je několik podobných proměnných, a proto musíme přidat
další slovo. Nebudeme tedy v Hello world aplikaci vytvářet proměnnou
textSPozdravemHelloWorld
, ale stačí nám jen
pozdrav
, pokud tam jiný není
Oddělení slov
Kvůli čitelnosti musíme slova v takovém názvu proměnné nějak oddělit:
- Více slov oddělujeme podle konvence daného programovacího jazyka. V
případě C# jde o tzv.
camelCase
(česky velbloudí notace, kdy každé další slovo začíná velkým písmenem a název pak vypadá jako hrby). V jiných jazycích se může používat např. podtržítko jakosnake_case
a další notace. - Vyhneme se pokud možno číslování proměnných a už vůbec nepíšeme
čísla slovy, ne
pozdrav2
anipozdravDve
. "Dvě" totiž neříká nic o tom, co pozdrav obsahuje.
Ukažme si to na příkladech:
✗ Špatně
string zprava1; string zpravaDve;
Zde není jasné, co je uloženo:
string prijato; // text, bajty, zprava, objednavka...? string odeslano;
A zde je název nečitelný:
string prijatazprava; string odeslanazprava;
✓ Správně
string prijataZprava; string odeslanaZprava;
Nepoužíváme zkratky
Tuto podkapitolu započněme citací:
Všichni si lámali hlavu nad tím, k čemu je ten sloupec
DATNAR
. Až se jednou zjistilo, že je to prý datum narození.
Tato špatná praktika je vlastně opakem víceslovných názvů
proměnných. Nevymýšlíme nesmyslné zkratky, například z názvu
pz
nikdo nepozná, že myslíme prijataZprava
.
Pomůcka může být:
Pokud se na kód podívá někdo jiný než my, měl by přesně vědět, co v které proměnné je.
✗ Špatně
string zp; int pz;
✓ Správně
string zprava; int pocetZprav;
Jak jsme slíbili, k tématu dobrých praktik se ještě několikrát vrátíme v podobných, spíše odpočinkových lekcích
V příští lekci, Textové řetězce v C# podruhé - Práce s jednotlivými znaky, na vás čeká překvapení