Jakmile se symbol skládá z více slov, tak mozek vypíná. Tudíž dlouhé jméno proměnné čitelnost rozhodně nezvyšuje. (U jmen tříd je to mírně jiné. Taky se s třídou pracuje jinak.)
Každopádně je to mýtus.
Dlouhé porměnné v Javě (i jinde) jsou zlozvyk.
Buď člověk umí zvolit správný název proměnné, tak aby reflektovala daný kontext:
i, x, xs, key, val, src, desc, parent, child
nebo to napsat neumí, a pak to bude hnůj krátkej nebo dlouhej.
Narazil jsem v Javě na pěkný kód i na juniorní kód. Délka metod v tom hraje roli spíš negativní.
Taky bych se vyhradil vůči té poznámce: jak zvolit, či zkrátit název není vůbec subjektivní. Je to inženýring.
Ty vaše krátké názvy jsou názornou ukázkou toho, jak by to skoro nikdy vypadat nemělo. U většiny dokážu uhodnout, jaké slovo to asi má znamenat, ale proč si to mám převádět ze zkratky ne celé slovo, proč tam to slovo nemůže být napsané? U xs
jsem to ani nedokázal dekódovat. x
naprosto univerzální název, může v tom být naprosto cokoli. Pokud neumíte něco správně pojmenovat, znamená to, že nevíte, co v tom doopravdy je.
Když jsou slova oddělená třeba pomocí CamelCase, není problém přečíst více slov. Název třídy, metody nebo proměnné má reflektovat, co v tom je nebo co to dělá. Ve spoustě případů je k tomu potřeba více slov a je to tak v pořádku. Mimochodem, pokud třídy, metody a proměnné pojmenováváte podle toho, co dělají, a vyjde vám někde příliš dlouhý název, znamená to, že toho ta třída či metoda asi dělá moc a měla by se rozdělit.
Tak zrovna to "x" je v nějakém matematičtějším kontextu naprosto jasné. "xs" nebo obecněji *s je zase zažité označení ve funkcionálních jazycích při rekurzivní práci se seznamy.
> Mimochodem, pokud třídy, metody a proměnné pojmenováváte podle toho, co dělají, a vyjde vám někde příliš dlouhý název, znamená to, že toho ta třída či metoda asi dělá moc a měla by se rozdělit.
A když tu složitou metodu rozdělím, tak ji na místech, kde se volala všude ručně zainlinuju? Nebo budu stále volat jednu metodu, jen interně složenou z dílků? A jak se teda má jmenovat?
Tak já trochu rozepíšu. V podstatě každá metoda toho dělá moc, pokud se díváme na detaily. A obvykle ty věci potřebujeme udělat, protože to vyžaduje business logika.
Takže pokud z toho vypadne moc dlouhý název není to proto, že toho ta metoda dělá moc, ale proto že přemýšlíme na špatné úrovni abstrakce. Místo dělění, kterým na té špatné úrovni uvázneme se to chce posunout na vyšší úroveň. Na vyšší úroveň, kde ta metoda dělá jednu věc a pojmenujeme ji podle toho.
Ano, v matematickém nebo geometrickém kontextu může být x jasné.
Když metodu pojmenováváte, ještě se nikde nevolá. Když se posunete na vyšší úroveň abstrakce při pojmenování metody, měl byste se posunout na vyšší úroveň abstrakce i při implementaci – úroveň abstrakce by se při pojmenování objektů měla zohledňovat také.
Naopak, toto je prostě jen praxe. Samozřejmě jsem také prožil ten mýtus, který autor blogového příspěvku propaguje.
Představa, že název proměnné má reflektovat co v tom je, nebo co to dělá je naprosto rigidní a nedostatečný požadavek. Název proměnné má v první řadě pomoct čtenáři kódu.
Když napíšu x
tak čtenář jasně pochopí, že se nemá snažit něco louskat, protože na významu té proměnné nezáleží. Což je přesně ten scénář, kdy přelejváte data z jednoho místa do jiného.
I kduž jsou slova oddělovaná až už pomocí CamelCase, nebo jakkoliv jinak, stále platí, že to je problém. Prostě je to všechno strašně dlouhý a užvaněný a komplikuje to čtení.
To, že je něco celým slovem, neznamená, že je to dlouhé a komplikuje to čtení. Právě naopak. Pokud má něco více slov, neznamená to, že je to dlouhé – velice často to pomáhá pochopení. Pokud má někdo problém s přečtením tří slov, asi by neměl programovat, protože při programování musí člověk číst pořád.
Zkracování názvů v drtivé většině případů nedává žádný smysl, naopak je kontraproduktivní. Jen opravdu ve výjimečných případech se setkávám s případem, kdy by nějaký název v programu byl zbytečně dlouhý. Lidé jsou přirozeně líní psát dlouhé názvy, i když je to prakticky nic nestojí. Naopak se často setkávám s případy, kdy je název špatně zvolený (ale ne příliš dlouhý) a je lepší název upravit (a klidně i prodloužit).
Takže vystupovat proti zbytečně dlouhým názvům znamená bojovat proti něčemu, co prakticky neexistuje. Pokud jste se s tím někde setkal, tak jste asi měl smůlu na špatný projekt.
Já vím, že troll se nemá krmit, ale ať je tedy legrace.
i je instance abstraktní třídy
x je proměnná, pro kterou kodér nechtěl vymášlet název (ještě neví, k čemu je dobrá)
xs je instance testovací třídy pro cross site scripting. Jen nevím, jestli je to payload, nebo něco jiného
key je kód stisknuté klávesy
src obsahuje IP adresu, odkud byl připojen klient
desc je ukazatel do pole ukazatelů na poštovní adresu balíku
parent je křestní jméno rodiče
child je příznak říkající, jestli ten rodič má nebo nemá děti
Že jsem se všude trefil?
desc je ukazatel do pole ukazatelů na poštovní adresu balíku
Líbí se mi, že když BoneFlute zřejmě udělal překlep, vy se toho dál držíte a používáte to i s tím překlepem. Vždyť čemu by měl vadit nějaký překlep, čitelnost a srozumitelnost přece nejsou potřeba – důležité je, aby to bylo krátké, na významu přece nezáleží.
Tak obvykle to kolegům stačí jednou popsat, a rádi to začnou používat.
Takže, pokud to neznáte:
i: čítač v ciklu, index
x: proměnná, jejíž název nás nezajímá, hodnota z kolekce
xs: kolekce, jejíž název nás nezamímá
key: klíč ve slovníku
val: hodnota ve slovníku
src: zdroj, ze které transformuju někam
dest: cíl, který krmím a následně ho pravděpodobně vrátím z funkce
parent: parent
child: child
Snad vám to pomůže. Jinak samozřejmě můžete trollit dál.
Proč val a ne value? Proč src a dest a ne source a destination? Sám jste v dest udělal překlep, kdyby tam bylo descination, code reviewer hned pochopí, že jde o překlep, u té zkratky mu to bude trvat podstatně déle. Hodnota z kolekce může být třeba item, x může znamenat milion různých věcí, takže je to obvykle špatný název.
Pracuji 8 let jako softwarový inženýr, specializuji se na backend a Javu. Na Root.cz jsem aktivní již 20 let. Jsem fanda do Unixu, který denně v práci použivám.