Odpovídáte na názor ke článku Proč Java používá tak dlouhé názvy tříd a proměnných.
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í CsvImportOrderService
je zcela na místě (i když bych se přikláněl k variantě CSVImportOrderService
, 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_service
, 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_string_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 CSVImportOrderService
za JSONImportOrderService
typicky vyžaduje úpravu konstruktoru (přinejmenším v tom smyslu, že už tam nemůžu posílat původní "orders.csv"
).
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.