Údržba kódu: Názvy

Kedysi sa názvam nevenovalo toľko pozornosti ako je tomu v dnešnom svete objektovo-orientovaného programovania. Teraz už záleží na každej banalite a z rôznych strán je možné počuť, čo všetko bude mať v budúcnosti nedozrierne následky. Treba povedať, že objektové programovanie prinieslo do programovania okrem nového spoôsobu myslenia aj čistejší a zároveň prehľadnejší kód.

Existujú dva spôsoby zápisu názvov, Pascal case, známy z jazyka Pascal, ktorý používa v každom novom slove prvé písmeno veľké a ostatné malé, napr. GetFileName, a potom spôsob zápisu Camel case, ktorý používa prvé písmeno v názve malé a každé v každom ďalšom slove používa veľké písmeno, napr.tempFileName. Ďalej bude uvedený aj tzv. Hungarian notation (maďarský spôsob), ktorý používa ako začiatočné písmeno názvu určitý typ, napr. pExp (pointer na Exp), rwPosition (Row ako riadok pozicie), ale aj strName (str ako typ string.

Všeobecne sa uvádza, že názvy by mali vysvetľovať význam, kvôli ktorému vznikli. Nie je vhodné, keď názov premennej vysvetľuje komentár.

Priznám sa, dlho som vyznával takýto spôsob pomenovávania. Tento zápis je pozostatok klasického procedurálneho programovania (napr. prvé verzie jazyka BASIC umožňovali použiť ako identifikátor len písmeno a číslicu), ktoré je charakteristické zmenou premenných, ich hodnôt, a keďže ich bežne v takomto type programovania nebolo málo, tak sa s obľubou používali rôzne písmenové označenia, nanajvýš dvojpísmenové a k tomu neskôr ešte nejaké tie podtržítka, aby to vyzeralo zložito a neprehľadne.

Nový štandard hovorí o tom, že je oveľa lepšie, keď daný komentár jednoducho použijeme v upravenej podobe za názov. Možno ma ešte napadá, že dôvod by mohol byť aj historický. V čase operačného systému MS DOS a nižsie, napr. CP/M bola maximálna dĺžka reťazca pre uloženie súboru 8 znakov, až s nástupom lepších OS pribudla možnosť používať tzv. „dlhé názvy“. Programátor to zrejme podvedome vnímal ako určité reštrikčné pravidlo.

Toto je správny zápis. Je potrebné si všimnúť malé písmeno na začiatku názvu, ktoré evokuje menší význam, než veľké písmeno, ktoré sa viac hodí na niečo, čo výraznejšie špecifikuje význam obsahu, napr. triedu.

Zaujímavá situácia nastane, ak sa v objektovom programovaní snažíme napísať procedurálny program. To je veľmi častý prípad. Väčšinou to vznikne, keď sa snažíme rýchlo prepísať myšlienku do algoritmu.

Podľa konvencií by to malo byť napísané nasledovným spôsobom:

Nezdá sa mi to celkom korektné a o úplnej správnosti by som polemizoval. Kým prvý kód je viac-menej všeobecne popisný, pretože premenná x môže pomenovávať akýkoľvek význam, tak druhý kód je tematicky orientovaný. Je z neho na prvý pohľad evidentné, že pôjde o nejaké hracie pole s jednotlivými políčkami. Teda paradoxne druhý kód, ak to nazveme v terminológii OOP, nie je tzv. „znovupoužiteľný“. Len do určitej miery. Názvy s označením cell vyjadrujú všeobecne nejakú bunku, ale hracia plocha s označením gameBoard už vyjadruje konkrétnu plochu – hraciu. Navyše takto sémenticky popisované názvy nútia k sémantickému premýšľaniu paralelne nad premýšľaním samotného algoritmu riešenia, a tiež kontrolou, či dané sémanticky popisované položky skutočne vyjadrujú podstatu. Niekedy sa ťažšie hľadá chyba v takomto kóde, pretože často to núti uveriť, že daný sémantický popis jednotlivých položiek naozaj vyjadruje to z akého dôvodu vznikli, až neskôr napr. zistíme, že ten flaggedCells sa rozlišuje aj podľa farby, ktorá z názvu nie je evidentná a navyše je definovaná kdesi na úplne inom mieste.

Často sa zvykne označovať akýkoľvek zoznam ako List, čo nie je vhodné, pretože programovacie jazyky bežne používajú tento identifikátor ako kontajner na objekty alebo premenné. Ak sa jedná skutočne o zoznam, tak je prípustné pomenovať identifikátor napr. accountList.

Je tiež vhodné používať názvy, ktoré sú dobre zapamätateľné a vysloviteľné, napr. názov na generovanie dátumu, roku, mesiaca, hodiny, minúty a sekundy nie je celkom zrozumiteľné napísať ako genymdhms. Tiež treba myslieť na to, aby daný názov bol niekedy v budúcnosti ľahko vyhľadateľný podľa mena. Keď si už priamo nespomenieme na úplný názov tak aj jeho čiastočný ekvivalent názov nám môže pomôcť v jeho nájdení.

Maďarská notácia zaviedla používanie názvov takým spôsobom, že na začiatku názvu sa nachádzalo jedno písmeno uvádzajúce typ identifikátora. Prvotne to bolo používané v jazyku Fortran, ale jeden slávny maďarský programátor to následne ešte rozvinul. Táto notácia bola veľmi často používaná vo Windows API (Win32 API) v jazyku C a v podstate sa používa dodnes. Takisto predponu m_ k názvom členských premenných už nemusíte pridávať. Triedy a metódy (funkcie) by mali byť dostatočne krátke, aby ste ich nepotrebovali. Tieto predpony a prípony často človek podvedome ignoruje a všíma si významnejšiu časť identifikátora. Po čase potom tieto rôzne prípony a predpony stratia význam a celkovo pôsobia v kóde zastaralo.

Rozhranie je vhodné označiť predponou I, teda napr. IShapeFactory, i keď niektorí autori od takého označenia odrádzajú. Dôvodom je podľa nich nadbytočná informácia. Podľa všetkého ak označíme rozhranie predponou I tak logicky by sme mali aj triedu označiť nejakou predponou a najvystížňejšie predponou C, napr. CShapeFactory. Avšak kým niektorí autori označenie rozhrania predponou I schvaľujú, označenie triedy predponou C už naopak neodporúčajú. Napr. v C++ knižnici MFC sa bežne používa označenie triedy s takouto predponou. Ale v jazykoch C# alebo Java to už príde ako nadbytočná informácia. Treba povedať, že dnešné moderné IDE už ponúkajú moderný prístup k formátovaniu a písaniu programového kódu, a preto by prakticky nebolo potrebné písať vôbec žiadne predpony. Rozhranie by bolo možné považovať za vyššiu abstrakciu, a preto z toho dôvodu je vhodné písať rozhranie s predponou, v ostatných prípadoch záleží na dohode.

Triedy a objekty môžu obsahovať podstatné mená alebo spojenie podstatných mien, napr. Customer, WikiPage, Account alebo AddressParser. V názvoch tried sa vyhnite názvom ako napr. Manager, Processor, Data alebo Info. Štylisticky sa upredňostňuje Pascal case, naopak u objektov skôr Camel case. Názov triedy by nemalo byť sloveso. Je tiež podstatné, aby trieda riešila jeden problém a nemala by byť veľmi dlhá. V prípade, že sa v nej už bude ťažko vyznať, mal by to byť signál, že niekde niečo nie je v poriadku a problém by sa mal dekomponovať na menšie časti.

Metódy (funkcie) by mali obsahovať slovesá, alebo slovesné frázy, napr. postPayment, deletePage alebo save. V procedurálnych jazykoch sa používali funkcie, v objektovom programovaní sa tieto funkcie nahradili názvom metód a to z toho dôvodu, že metóda vyjadruje správanie objektu, predstavuje nejakú činnosť, ktorá je vyjadriteľná práve slovesným tvarom. Prístupové objekty, mutátory a predikáty by mali byť pomenované podľa svojej hodnoty a s predponou get, set alebo is podľa použitého štandardu toho ktorého programovacieho jazyka. Štylisticky sa zvykne používať pre signatúru metódy typ Pascal case a pre jej parametre typ Camel case.

Ono stále záleží na firemnej kultúre, na jej používanej konvencii písania názvov. V prípade, že udržiavate prevzatý kód používajte k riešeniu týchto problémov nástroje pre refaktorovanie. Ale o tom niekedy nabudúce.

You may also like...