Zpět

Hlavně se v tom neztratit

"To už je tak složitý, že se v tom vůbec nevyznám!"

Touhle nebo podobnou větou programátor přiznává kapitulaci. Jestli mluví o programu, který po někom přebral, má to aspoň na koho svést, ale jestli ho psal od začátku sám, je to ostuda. V následujícím textu se pokusím shrnout pár obecných doporučení a příkladů, jak se podobným problémům vyhnout.

Ideální situace vypadá tak, že začínáte "na zelené louce" s prázdným PLC a cílový stav je správně fungující stroj, ke kterému už se nikdy nemusíte vracet a opravovat chyby. Praxe často vypadá trochu jinak: někdy začínáte s prastarou mašinou, kterou je potřeba "jenom trochu upravit" (pokud možno za plného provozu), jindy si zákazník třeba za rok vzpomene, že by chtěl doprogramovat novou funkci nebo změnit výrobní postup. Srozumitelnost kódu má potom naprosto zásadní vliv na to, za jak dlouho práci stihnete, a rozdíl může být klidně i několik řádů (minuty vs. dny).

Výstižné identifikátory

Tohle je ze všeho nejdůležitější věc, proto ji píšu hned na začátek. Další odstavce ji víceméně jenom rozebírají z různých úhlů. (Nezávisle napsaná série článků Umíš pojmenovat proměnné? na Itnetworku mě o několik let předběhla s datem vydání. Aspoň je vidět, že nejsem jediný, kdo tenhle styl doporučuje.)

Když se proměnná jmenuje D, nic moc nám to neřekne. Když se jmenuje Diry, pořád ještě není úplně jasné, k čemu přesně slouží (na první pohled bych tipoval nejspíš pole informací o nějakých dírách). Až PocetDer už dává jednoznačný smysl. Vyplatí se psát jména tak, aby z nich bylo poznat, co znamenají: CisloProgramu, PocetReceptur, Dil1Zalozen, MotorHlasiChybu a podobně.

Psát víceslovné názvy dohromadybezodlišeníslov není moc přehledné, tak se na to používá několik různých stylů. Tzv. pascal case (VšechnaPrvníPísmenaVelká) a camel case (prvníMaléOstatníVelká) se hodí pro jazyky, které nerozlišují velikost písmen v identifikátorech (pascal, ST atd.): pokud se spletete a zapomenete zmáčknout Shift, nevadí to, je to pořád to samé. Kde se velikost rozlišuje (C a jemu podobné), tam si to buď musíte hodně dobře hlídat, nebo používat snake case (všechno_malými_oddělováno_podtržítky, viz např. PHP). Slova-oddělená-pomlčkami používá snad jedině Cobol (kolem mínusů se pak musí psát mezery, aby se to nepletlo). Některé překladače dovolují psát jména s mezerami (např. TIA Portal nebo Filemaker), ale to moc nedoporučuji, je s tím víc problémů než užitku - nutnost používat uvozovky a podobně. Ať už se rozhodnete pro jakýkoli styl, doporučuji dodržovat ho jednotně v celém programu, abyste si nemuseli u každé proměnné pamatovat kromě jména i jak se píše (nejhorší zmatky nastávají, když se vyskytnou dvě různé proměnné lišící se jenom stylem jména).

Logickým proměnným (Boolean - true/false, 1/0, ano/ne) je dobré dávat jména, jaká odpovídají stavu True: PistJeDole, MotorStoji, Nalezeno, VybranaLevaStrana a podobně. Kdyby se proměnná jmenovala třeba PolohaPistu, nemáme šanci poznat, jestli true=dole a false=nahoře, nebo přesně naopak.

Některé prameny doporučují v anglických zdrojácích začínat jména booleanů slovem "is" nebo "has" ("je" nebo "má"). Má to svoji logiku, ale univerzálně použitelné to je asi jenom pro atributy objektů. V neobjektových jazycích příliš často potřebujeme jiný slovosled, aby to neznělo jako otázka (IsMotorRunning vs. MotorIsRunning) nebo něco úplně jiného.

Velký pozor si dávejte na nejednoznačnosti. Typický příklad: PistVpravo. Je to povel k pohybu pístu doprava, nebo signál, že píst je vpravo? Vyplatí se důkladně se nad každou proměnnou zamyslet a dát jí jméno třeba i delší a kostrbatější, ale jednoznačné: PosunPistDoprava, PistJeVpravo; SpustKontrolu, KontrolaJeHotova; NastalaChyba, CisloChyby a podobně.

Šikovná finta k odlišení procedur a funkcí od proměnných je použití rozkazovacího slovesa v názvu ("udělej něco"). Třeba ZjistiJmenoUzivatele - na první pohled je vidět, že to má něco dělat, zatímco JmenoUzivatele vypadá spíš jako proměnná, kde to jméno máme uložené.

Nemíchejte jazyky

Teď nemyslím jazyk, kterým program mluví na uživatele, ale jazyk, kterým ve zdrojáku píšete identifikátory a komentáře. Někdy si to zákazník výslovně určí (záleží na tom, s kým spolupracujete a kdo se o kód potom bude starat), někdy je mu to jedno a můžete si vybrat. Ať už to dopadne jakkoli, doporučuji držet se výhradně jednoho a nemíchat do toho žádný další. Směsici češtiny a angličtiny totiž pořádně nerozumí ani Čech, ani Angličan. A i když někdo zná všechny jazyky, které jsou ve zdrojáku použité, nemá ještě vyhráno, protože u některých slov (hlavně zkratek) není poznat, ve kterém jazyce vlastně jsou. Je "Prt" zkratka anglického "Part", "Print" nebo českého "Pritomnost"? Radši se úplně vyhněte slabice "No", protože ta může znamenat jak nezkrácené slovo "ne", tak zkratku pro "number", a občas to dává úplně opačný význam. Typický příklad: NoErrors - je to "number of errors" neboli počet chyb (0 = všechno v pořádku), nebo příznak "no errors" neboli žádné chyby (0 = máme problém)?

Další úroveň šifrování přidávají překlepy a gramatické chyby. V normálním textu tolik nevadí, ale když může jedno pozměněné písmenko vytvořit úplně jiné platné slovo ve druhém jazyce, je to horší. Je "Pas" české označení dopravního pásu, nebo anglické "Pass"? Je "Pich" povel k vysunutí propichovací jehly, nebo jenom zkomolená "Pitch", čili rozteč? Některé editory umí automaticky dokončovat rozepsaná slova, takže vám chybu úslužně rozkopírují napříč celým programem.

Neanglické jazyky mají výhodu, že se identifikátory nepletou s vyhrazenými slovy a že na první pohled poznáte, co je součást vašeho programu a co systémová funkce. Angličtina má zase výhodu, že můžete svůj zdroják snadno konzultovat s technickou podporou výrobce (pokud zrovna nemá ve vašem okolí schopného českého zástupce). A v neposlední řadě má jakýkoli mateřský jazyk výhodu, že ho ovládáte ze všech nejlíp a nevnášíte si do programování ještě starosti s překladem.

Pozor na zkratky

Je "Cam" zkrácená "Camera", nebo je to opravdu jenom "Cam" neboli vačka? "Lt" je "Left", "Light" nebo "Length"? Může "Str" znamenat "Strana", "Střed", "Start", nebo něco úplně jiného? Uznávám, že je otrava psát pořád dokola "Dil1Zalozen" nebo "ZavriChapadlo", ale ve výsledku to zabere míň času než po půl roce marně vzpomínat, co znamená "D1prt" nebo "CHZ". Vřele doporučuji naučit se datlovat všemi deseti bez koukání na klávesnici, ušetří to dobrou třetinu pracovní doby.

Další úskalí zkratek je nejednoznačnost. Typicky a nejčastěji "Zap" a "Vyp": jsou to povely "Zapnout" a "Vypnout", nebo signály "Zapnuto" a "Vypnuto"? Stejný problém má i angličtina, "On" a "Off" jsou dvojznačné i bez zkracování. Tady je opravdu nutné psát celé slovo a v případě potřeby přidat i další (např. "PowerOn" rozlišit na "PowerIsOn" a "TurnPowerOn").

Šetřete negacemi

"Nemohu neříci, že nejsem nerad" - a co tím vlastně chci říci? Negace logických výrazů je triviální operace, ale když se to s nimi přežene, člověk ztrácí přehled, kolik záporů se navzájem vyrušilo a kolik jich ještě zbývá.

Typický příklad jsou signály z optických závor: v neaktivním stavu svítí, a když přerušíte paprsek vložením předmětu, zhasnou. Osvědčilo se mi takový signál vždycky pojmenovat kladně, třeba "Dil1JePryc", než negovaně, třeba "Dil1NeniZalozen". Když potom signál někde používám znegovaný, zápis "NOT je pryč" se mi čte líp než "NOT není tu" - nemusím v duchu počítat zápory a nemate mě přítomnost slova s opačným významem.

Vyplatí se přejmenovat si i nevhodně nazvané signály z různých externích zařízení. Typicky např. něco, co se podle manuálu jmenuje "ERROR" a přitom to má při výskytu chyby zhasnout - to bych si interně pojmenoval třeba "OK".

Komentujte hodnoty, ne operace

U příkazu Poloha:=59 je zcela zbytečné psát si poznámku "nastavení požadované polohy" - to z názvu proměnné a přiřazovacího operátoru pochopí každý na první pohled. Mnohem užitečnější je poznamenat si, že 59 je výchozí poloha těsně nad stolem - to neví nikdo kromě vás (a ani vy si to nebudete pamatovat věčně). Případné další podrobnosti jako že kladný směr je nahoru a jednotky jsou desetiny milimetru taky nejsou na škodu, ale uklidil bych je někam k deklaraci proměnné Poloha.

Je samozřejmě možné se všem "magickým" hodnotám vyhnout a nahradit je vhodně pojmenovanými konstantami. Má to svoje výhody, hlavně když se jedno číslo používá na více místech a potřebujete ho měnit všude stejně. Ale poměrně často zjistíte, že je program přehlednější, když jsou čísla uvedená přímo ve výkonném kódu: nemusíte pořád překlikávat mezi pracovním cyklem a oblastí definic. To je výhoda hlavně při luštění cizího kódu, kdy potřebujete udržet v paměti dost věcí a při každém skoku na jiné místo hrozí, že vám něco vypadne.

Zpět