Vlákno názorů ke článku Proč Java používá tak dlouhé názvy tříd a proměnných od Josef Marianek - Za me nesouhlas. Nazvy jako ExternalOrder­Service jsem kdysi...

Za me nesouhlas. Nazvy jako ExternalOrder­Service jsem kdysi pouzival, pozdeji jsem to zkratil na dejme tomu ExtOrderSvc. V bash taky nepisete move ale mv atp. Proste lenost. Nerikam ze ten nazev ma byt nerikajici eos, ale proste kratsi a porad smysluplny, aby se clovek neupsal k smrti...

Tak u typu to klidně rozepíšu, ale u proměnné zkracuju podstatně agresivněji. Přece jenom proměnné obvykle existují v podstatně kratším scopu než typy. A délka názvu by se měla vybírat podle vělikosti scopu.

A pak máme zažité věci jako "i", "x", "src", "dst" a podobně. Tam opravdu není problém v tom, že čtenář neví, co ta zkratka znamená. Takže rozepsat to na plný název samo o sobě stejně nestačí.

Argumentujete tím, že zkrácení ničemu nevadí, že pravděpodobnost, že by tu zkratku někdo nerozpoznal, je mizivá. Ale proč bych měl vůbec zkracovat? Jaký je přínos?

To je super ušetřil jsi celých 9 písmenek, opravdu ti tleskám. Ale až k tomu někdo přijde za půl roku, tak nebude vědět, jestli to je ExternalOrder­Service nebo ExtendedOrder­Service a to se opravdu vyplatí.
Vážně by mě zajímal jediný rozumný důvod proč tohle dělat. Předpokládám, že stejně ty typy nikdo nepíše v textovém editoru a používá IDE, takže i těch 9 ušetřených písmenek ti při psaní nepomůže, spíš naopak, protože nebudeš vědět, jestli to náhodou nebylo ExternOrderSvc nebo ExtrnOrdrSvc (ano i takové experty jsem potkal co vynechávali samohlásky).

Co dokumentacni komentare? Dale podle me se moc dlouhyma nazvama citelnost nezlepsi, radky se natahuji. Mluvil jsem o kompromisu.
Jinak souhlasim jak na me nekdo reagoval v tim scope typu a promenne, tj. nejaka lok. promenna muze mit opravu malo vyznamny nazev, typ si zaslouzi delsi.

Dokumentační komentář je ta poslední možnost, která se použije v případě, kdy něco nejde vyjádřit přímo v kódu. Dokumentačnímu komentáři totiž nerozumí IDE ani jiné nástroje pro práci s kódem. Závisí na tom, že si ho někdo přečte. A nejde nijak zaručit, že je v souladu s kódem.

Dale podle me se moc dlouhyma nazvama citelnost nezlepsi, radky se natahuji.
Moc dlouhé názvy se ale vyskytují málokdy.

Když k tomu přijdu za půl roku, tak se i na tu ExternalOrder­Service budu muset podívat blíž. Třeba netuším jestli je to External-OrderService nebo ExternalOrder-Service. Jestli je to externí z pohledu implementace (třeba někde na síti) nebo z pohledu business logiky (třeba objednávky nejakých externistů).

Jo, zkrátit to o pár znaků ušetří houby. Ale rozepsáním na celá slova získám taky velké kulové. Do rozumně použitelného identifikátoru toho moc nenacpu i kdybych se na hlavu stavěl.

Zkracování pomáhá čitelnosti spíš jinak, třeba že se ten kód musí míň zalamovat.

Třeba netuším jestli je to External-OrderService nebo ExternalOrder-Service.
To obvykle tušíte, protože v doméně, kterou řešíte, se vyskytuje jedno nebo druhé, ale ne obojí.

Ale rozepsáním na celá slova získám taky velké kulové.
Rozepsáním na celá slova získáte to, že každý, kdo si to přečte, se okamžitě dostane do nějakého kontextu. A nebude muset nejprve dekódovat, co by asi tak mohly znamenat nějaké zkratky.

Do rozumně použitelného identifikátoru toho moc nenacpu i kdybych se na hlavu stavěl.
Bylo tady uvedeno dost příkladů rozumně použitelných identifikátorů, ve kterých je dostatek informací. Další tisíce příkladů najdete třeba v Java SDK, nebo ve spoustě knihoven (třeba Spring či Micronaut, když zůstaneme ve světě Javy, abych uvedl alespoň pár dalších případů).

Jo, zkrátit to o pár znaků ušetří houby. Ale rozepsáním na celá slova získám taky velké kulové.
Právě, že získám. Většina IDE umí doplňovat podle prefixu slov proměnných (nevím jak to nazvat), takže když napíšu ExOrS tak mi to nabídne ExternalOrder­Service. Pokud to, ale zkrátím na ExtOrderSvc a napíšu v IDE ExteOrSer, tak mi IDE již ExtOrderSvc nenabídne. Takže tím, že to rozepíšu dovolím všem mnohem lépe vyhledávat a zároveň i lidem co mají problém s dlouhými názvy můžou používat své zkratky a IDE jim to doplní do plného názvu.

Ono na vyřazení IDE úplně stačí zkrátit to jen na ExternalOrderSvc a pak napsat naprosto běžné ExOrSe nebo EOSe. Zkracování slov zprava jenom ztěžuje čitelnost, ale vypouštění znaků z prostředka slov by při programování mělo být trestné. I pro skeletové zkratky samozřejmě mohou existovat výjimky, ale jedině v případě, že je ta zkratka v týmu velmi dobře známá a používá se výhradně ta zkratka, tj. nehrozí, že budu muset pokaždé dumat zda je to Svc nebo Service.

Já tady jako předřečník také nesouhlasím. Fakt tím neušetříte vůbec nic, jen naserete ostatní. Že je service externí mne vůbec nezajímá, tam bych třeba ušetřil OrderService třeba, ale zkomolit Service na Svc to je už na hraně šílenství. Jako zkratky ano, ale musí se dohodnout předem, třeba `qty` jako quantity atd.

Normálně se fakt nebát dlouhých názvů... z naší apliakace:

@dataclass(frozen=True, slots=True)
class TranscriptAnalysed(Event[Transcript]):
    date: date
    station_id: StationID

oi byste navrhoval? `TransAnal`?

TranscriptAnalysed je podle me ok (rozumne kratke :)

Jako vážně? Délka ExternalOrder­Service se liší o celé 3 znaky. Jako je tak velký rozdíl mezi 19 a 22 znaků?

Já nemám původně technické vzdělání, ale humanitní až umělecké a pak až přírodovědně a na tohle mám fakt pifku. Stejně jako na "working code over documentation" a podobná moudra a mantry, která ale nakonec vyústí v to, že kromě autora v tom nakonec každý plave. Autor kódu se po pár měsících v plavání přidá a toho v tom pak nejlíp i utopit. :D