Vlákno názorů ke článku Proč Java používá tak dlouhé názvy tříd a proměnných od Ravise - Trochu mě mrzí, že blog i diskuse bere...

Trochu mě mrzí, že blog i diskuse bere problém jako java vs. zbytek (neesoterického) programovacího světa, popřípadě java vs. "ty prasata co skriptují v pythonu". Výstižně něco pojmenovat je těžké, a na jazyce téměř nezáleží.

Záleží na tom, jak dlouho žije věc pod tím kterým jménem schovaná. Třídy/typy žijí tak dlouho jako program, a pojmenování CsvImportOrder­Service je zcela na místě (i když bych se přikláněl k variantě CSVImportOrder­Service, ale to je pro tuhle diskusi nepodstatné). Ale nevidím důvod, proč pojmenovat proměnnou tak úzce podle typu. Buď se k ní můžu chovat jako k nějaké import_order_ser­vice, a pak prefix csv_ přispívá k šumu spíš než k signálu; anebo nebo ne, a potom by se tak neměla jmenovat v první řadě ta třída, ne?

Co se argumentu přehlednosti týče, dlouhé názvy jsou pro mě (osobně) spíš známkou špatného členění programu. Idea funkce by měla jít popsat nejlépe jednou větou, a v takovém rozsahu si dovolím používat jména o "pár" písmenech. Když totiž vidím (a dokážu najednou mentálně uchopit) celý vnitřek funkce, tak mezi buf a file_like_strin­g_buffer není žádný rozdíl. To druhé jméno se navíc rozbije ve chvíli, kdy přestanu psát znaky a začnu psát bajty. A když to neopravím, zmatu každého čtenáře.

Lokální a privátní jména můžou být krátká, protože je "na místě zjevné", k čemu se vážou. Vidím, kde vznikají, vidím, proč existují a vidím, kde zanikají. Veřejná a globální jména (už jsem se zmiňoval o typech a třídách) žijí kdoví kde, používá je kdosi kdesi a náhrada CSVImportOrder­Service za JSONImportOrder­Service typicky vyžaduje úpravu konstruktoru (přinejmenším v tom smyslu, že už tam nemůžu posílat původní "orders.csv").

Když totiž vidím (a dokážu najednou mentálně uchopit) celý vnitřek funkce, tak mezi buf a file_like_strin­g_buffer není žádný rozdíl.
Rozdíl ale bude, když vnitřek té funkce neuvidíte. A existuje spousta programů, kde není možné zkoumat vnitřek každé funkce, kterou chci použít (a někdy ani nemusím zdroják té funkce mít).

Pak ale nevidím/nemám vidět/nepotřebuju vidět ani název té proměnné.

Vztahoval jsem to na název funkce.

Mimochodem, ta poznámka s bajty a znaky byl přesně příklad, kdy by to jméno mělo být popisné. Pokud se změní význam proměnné, a zejména takovým způsobem, kdy může snadno dojít k záměně, jako jsou bajty a znaky, a proměnná se při takové změně nemusí přejmenovat, je to znak, že byla pojmenovaná špatně.

Mimochodem, to, že by kód funkce měl být krátký a pochopitelný je pravda, ale z kódu poznáte co to dělá, ale proč si musíte odvodit. A když to není zřejmé, správné pojmenování tomu právě může významně pomoci. Pak je ještě možnost dopsat tam komentář, ale podle mne to, co jde vyřešit úpravou kódu, aby byl čitelnější, by mělo být řešení v kódu. Komentář považuju až za poslední možnost, když to nejde jinak.

Třeba porovnejte tyhle dva příklady:

if (vek < 18) {
  return <Chyba message="Alkohol vám nemůžeme prodat."/>
}

const jePlnolety = (vek >= 18)
if (!jePlnolety) {
  return <Chyba message="Alkohol vám nemůžeme prodat."/>
}

V prvním případě musíte vědět, že se v ČR nesmí prodávat alkohol neplnoletým a hranice plnoletosti v ČR je 18 let. Bez toho nebudete vědět, kde se tam ta osmnáctka vzala. V druhém případě je zavedená proměnná, která je z hlediska kódu úplně zbytečná, ale slouží k pojmenování významu toho výrazu vek >= 18. V názvu proměnné se vyskytuje ten termín „plnoletost“, který v prvním příkladu vůbec není, takže to dost pomůže pochopení významu toho kódu.

> Vztahoval jsem to na název funkce.

Zcestně. Ale chyba je na mojí straně - co jsem taky čekal.

> Třeba porovnejte tyhle dva příklady:

No, příklady jsem porovnal, a v obou je ta zásadní chyba, že místo vhodně pojmenované konstanty používají magickou osmnáctku. Zkusme si do obou příkladů mentálně dosadit vek < MIN_AGE_TO_BU­Y_ALCOHOL a najednou to prokoukne, že?

Buď se k ní můžu chovat jako k nějaké import_order_ser­vice, a pak prefix csv_ přispívá k šumu spíš než k signálu; anebo nebo ne, a potom by se tak neměla jmenovat v první řadě ta třída, ne?
Tohle je špatný příklad. Kdyby tam to csv nebylo, tak bych předpokládal, že typ toho order bude jen nějaký interface jako ImportOrderSer­vice a pak dává smysl proměnnou pojmenovat jako import_order_ser­vice. Tím odebráním csv jsi ztratil důležitou informaci a v případě, že budeš mít ještě typy XmlimportOrder­Service, tak jsi v koncích a musíš u takové proměnné stále kontrolovat co je to za typ.

Obecně si myslím, že k tomu nezkracovat názvy se musí člověk protrpět. Ono taky ne každý dělá na projektu s více lidmi, který běží několik let. Je jasné, že lidem co dělají na projektu sami tohle přijde divné, ale když musíte luštit co ten člověk před 5 lety chtěl dělat a názvy proměnných jsou x, y nebo buf, tak je to vážně k zlosti

Osobně vidím stejné dilema, jenže obráceně: proč je pro mě podstatné, že je to zrovna CSVImportOrder­Service? Všechny věci, které jsou pro csv specifické za mě řeší ta třída (od toho přeci je), a tam, kde se držím rozhraní, zase nezáleží, jestli je implementací csv nebo sqlite (ať se neopakujeme :))

Nehledě na to, že pokud mi ta služba přiteče parametrem, tak ten bude stejně skoro vždycky typu ImportOrderSer­viceInterface. Ze situací, kdy tomu tak nebude, mě napadají serializace a debugovací pohledy dovnitř objektu, a obě tyhle situace mohou být stejně pokryté interfacem a metodou - tyhle věci budu chtít dělat ať už budu mít pod rukama instanci CSVImportOrder­Service nebo XLSXImportOrder­Service.

Jediné místo, které je opravdu specifické pro csv bude konstruktor (nebo pár řádků těsně za ním), kde budu nastavovat oddělovače, konce řádků, skutečný zdroj těch dat atp., a tam je zase spousta věcí zřejmá z kontextu. Ani tam bych se nedržel typu tak úzce, protože zítra nebo příští týden z toho bude switch a příští měsíc ImportOrderSer­viceFactory.

proč je pro mě podstatné, že je to zrovna CSVImportOrder­Service? Všechny věci, které jsou pro csv specifické za mě řeší ta třída (od toho přeci je)
Ta třída určitě není od toho, aby řešila všechny věci specifické pro CSV. Jednoduchý příklad – budete mít další služby se stejným rozhraním, ovšem pro XML, JSON atd. Nejprve budete muset detekovat typ souboru, a pak podle toho zavolat službu pro CSV, XML, JSON apod.

Nehledě na to, že pokud mi ta služba přiteče parametrem, tak ten bude stejně skoro vždycky typu ImportOrderSer­viceInterface.
Nebo také bude typu CSVImportOrder­Service. Protože z ničeho jiného, než z CSV, v tuto chvíli objednávky importovat neumíte. Tak proč vytvářet nějaký zbytečný interface?

tam je zase spousta věcí zřejmá z kontextu.
Co tím zkrácením názvu získáte? Vy musíte přemýšlet, jak název zkrátit. Každý, kdo kód čte, pak musí přemýšlet, jestli importOrderSer­vice je CsvImportOrder­Service, nebo jestli to náhodou nemůže být něco jiného. Ano, někdy to zkrácení může mít význam. Ale ten postup by měl být přesně opačný, než říkáte vy – by default název nechám, ale pokud je k tomu důvod, mohu ho změnit (zkrátit nebo i prodloužit). Nebudu ho zkracovat jen tak, protože to jde – zkrácením bez dalšího důvodu nic nezískám.

> Nebo také bude typu CSVImportOrder­Service. Protože z ničeho jiného, než z CSV, v tuto chvíli objednávky importovat neumíte. Tak proč vytvářet nějaký zbytečný interface?

Pokud umím jenom csv, tak ten CSVImportOrder­Service dává smysl ještě míň. Za prvé nepotřebuju odlišit ten csv service od nějakých jiných. A za druhé, což je ještě důležitější, si to omezení na csv tak tvrdě neprodrátuju skrz celý kód.

Z nějaké ImportOrderService můžu udělat interface nebo předka, když budu potřebovat podporu i pro něco jiného než csv. Budu mít nové CSVImportOdrder­Service a NecoImportOrder­Service, ale stávajícího kódu se dost často nebudu muset vbec dotknout, pokud jsem rozhraní té třídy napsal nějak příčetně.

Ok, můžu automaticky přejměnovat ten typ, a podstatně méně automaticky hromadu proměnných "csvImportOrder­Service". Merge takového commitu může být sranda.

> Ta třída určitě není od toho, aby řešila všechny věci specifické pro CSV.

Ne. Ta třída je tam doslova pro to, aby za mě řešila parsování csvčka, transformaci z řádků na záznamy a vůbec obsluhu toho zdroje.

> Nejprve budete muset detekovat typ souboru, a pak podle toho zavolat službu pro CSV, XML, JSON apod.

Tím spíš tu proměnnou nepojmenuji podle CSVčka, protože to může být třeba yaml.

> Co tím zkrácením názvu získáte?

Lepší odstup signálu od šumu.

> Vy musíte přemýšlet, jak název zkrátit.

Nepřeju si, aby mi kdokoliv vkládal slova do úst! Já tak činit nemusím, a ani tak nečiním. Tohle si fakt od nikoho, kdo do kódu zapeče 18, protože každý ví, že je to limit věku pro nákup alkoholu, líbit nenechám.

Pro všechny ostatní - asi bych tu myšlenku mohl verbalizovat. Neřeším jenom informační obsah (i když ten je důležitý), ale taky odstup signálu od šumu. Jsou věci, které přináši informaci, ale nepřináší podstatnou informaci. Nechci čtenáře kódu utopit informacemi, které jsou sice pravdivé, ale v kontextu použití zbytečné (a v nejhorším případě zastaralé).

Jenže co když CSVImportOrder­Service a XMLImportOrder­Service mají jiné rozhraní? Např. u xml musím definovat ještě něco navíc verzi, schema atp.

Takové věci si právě představuju, že budou řešené hned za konstruktorem. Tam tu informaci o typu nese sám konstruktor. Ideálně tohle všechno pojme hned sám konstruktor, ale dokážu si představit i důvody, proč tyhle věci vystavit zvlášť. Ale jinak by ta třída měla poskytovat rozhraní nezávislé na tom, odkud ty objednávky importuju. Něco jako "validuj", "počet záznamů", "proveď import", "dej iterátor přes záznamy".