===== Nazvoslovie =====
Vyber dobrych mien si vyzaduje dobre popisne schopnosti a to je viac vecou ucenia a osobnosti ako vecou technickou. Zial vysledkom potom byva, ze sa to vela programatorov nenauci dobre. Aj preto sa netreba bat zmenit nespravny nazov len pre to, aby neboli ostatni programatori zaskoceni. Pokial sa citatelnost kodu zlepsi je to dobre.
==== Vysvetlenie vyznamu ====
Meno premennej, funkcie alebo triedy by malo zodpovedat vsetky zasadne otazky. Na co sluzi, preco existuje a ako sa ma pouzivat. Pokial vyzaduje poznamku, tak svoj vyznam skryva a pri citani kodu sa potom zbytocne zdrzuje hladanim vyznamu v poznamkach. Dalej vyber spravneho mena velmi ulahci a urychli aj pochopenie kodu. Pre porovnanie zly nazov
int d; // elapsed time in days
a dobry nazov
int elapsedTimeInDays;
==== Dezinformacie ====
Nie je nic horsie ako ked nazov premennej alebo funkcie robi nieco ine ako hovori jej nazov. Tomu sa povie sabotaz :-). Neprijemne su ale aj nasledovne situacie:
* Nazov v sebe obsahuje vseobecne pouzivany symbol - napr. //std// pre secondsToDate.
* Pozor na viac vyznamove premenne ako napr. //secTime//, kde moze ist o cas v sekundach alebo druhy cas.
* Pokial sa nieco vola //accountList// mal by to byt list, inak je lepsie nazvat to iba //accounts//.
* Specialne pozor na nazvy s l a 1 a O a 0 (schvalne nech nevidno rozdiel).
* Nazvy su si podobne ako vajce vajcu: //ClassForEfficeientHandlingOfString// a //ClassForEfficientStorageOfString//.
* Nazvy stylu //funkcia1()//, //funkcia2()// ...
Napriklad:
int copyChars(char *a1, char *a2);
oproti lepsiemu
int copyChars(char *destination, char *source)
==== Dalsie poznamky ====
Dalej je dobre mysliet aj na:
* Vyslovitelnemena na rozdiel od nevyslvitelnych maju tu vyhodu, ze sa o nich da rozpravat medzi programatormi (programovanie je socialna cinnost).
* Lahko vyhladavatelne mena (hladat //item// v projekte je tazsie ako hladat //webPageUrl//).
* Nekodovat do nazvov typ premennej (Madarska notacia: pcName = char *Name)
* Kratsie mena su lepsie ako dlhe, pokial su zrozumitelne a obsahuju vsetky potrebne informacie.
* Nepridavat prefixy ako napr. m_ v clenskych premennych, (lepsie je pouzit lokalnu triedu pre clenske premenne vid: [[coding:rules_k10|Triedy]]) ani bezdvovodne kontext navyse ako napr. (//FPDstatus// ako //FiscalPrinterDriver//), historickou vynimkou je nase //E//vsetko.
* V pripadoch ked sa treba rozhodnut, ci pridat I ako Interface, alebo I ako implementaciu, je vhodne pouzit pravidlo: "Co sa viac pouziva ma menej pismen", takze namiesto //IConnetion//, alebo //ConnectionIface// pouzit radsej //Connection// a ako implementaciu //ConnectionImp//.
* Kod budu citat programatori, takze je mozne pouzivat programatorske terminy.
* Pokial nie je zauzivany programatorsky termin, je vhodne pouzivanie mien domeny problemu (napr. OneWayTicket).
* Nie je dobre pouzivat slovne hracky, zajedno 40 krat citany vtip uz nie je vtipny, nie kazdy ma podobny zmysel pre humor a zbytocne to zatazuje mozog. (Ak niekoho napadne slovna hracka nech ju radsej kolegom pre zasmiatie povie, alebo twitne, ocenia to viac).
* V triedach je lepsie ak sa to da vyhnut prilis vseobecnym nazovm ako: //Manager//, //Procesor//, //Data// alebo //Info//.