Odpověď na názor

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").