Proč Java používá tak dlouhé názvy tříd a proměnných
Častokrát slyším stížnosti u lidí, kteří nejsou úplně fandové do Javy, že se v ní píší sáhodlouhé názvy tříd a proměnných. Např:
OrderService.java ExternalOrderService.java CsvImportOrderService.java
A k nim následně názvy instancí:
final var orderService = new OrderService(); final var externalOrderService = new ExternalOrderService(); final var csvImportOrderService = new CsvImportOrderService();
Na první pohled není člověku, co píše skripty v Pythonu, jasné, proč se něco takového děje. Důvod není úplně snadné pochopit, než se člověk dostane do praxe jako Java vývojář.
Tím hlavním důvodem je pořádek v kódu v ten moment, kdy na vyvíjené aplikaci pracuje více než jeden člověk najednou, a navíc se tato aplikace bude vyvíjet dalších řekněme 20 let a vystřídá se na ní za tu dobu klidně 15 vývojářů.
Tím je už teď řečeno vše, ne? Ale pokud ne, tak to ještě rozeberu.
Ono totiž vhodně zkrátit název něčeho není úplně jednoduché. Jednak to vyžaduje práci, druhak, a to je ten hlavní důvod, je to dost subjektivní, individuální věc. Každý má trochu jiné chutě, jak by název proměnných a tříd zkrátil. Totiž dlouhý nezkrácený název je takový konsensus napříč vývojáři, je to dohoda.
Problém s čitelností se tím navíc zlepší. Po pár letech praxe člověk zjistí, že když má aplikace 300000 řádků kódu, tak to poslední, co mu bude při čtení kódu vadit, je, že něco má dlouhé názvy. To totiž není něco, co tvoří složitost kódu – ta se luští nejhůře. Přečíst delší název proměnné moc úsilí nestojí. Delší názvy proměnné nezvyšují v 300000 řádkové aplikaci složitost, ba právě naopak, snižují jí tím, že zvyšují přehlednost.
Navíc delší názvy proměnných jsou lépe deskriptivní, což uvítá váš kolega vývojář, který bude po vás kód číst a luštit. Nemusí se zamýšlet jak byla ta či ona zkratka čehosi vlastně myšlena.
-
V podstatě s autorem souhlasím, přehnané zkracování čitelnosti obvykle spíše škodí. Na druhou stranu, nic se nesmí přehánět, protože tupým aplikováním pravidel mohou vznikat strašné věci. Jeden odstrašující příklad za všechny: HasThisTypePatternTriedToSneakInSomeGenericOrParameterizedTypePatternMatchingStuffAnywhereVisitor.
-
Taktiez plne suhlasim. On ten nazov by mal byt rozumny, ak je nazov premennej/class/metody nejaky dlhsi, tak potom je lepsie k tomu zapisat nejaky komentar, kde uz moze byt aj kratsia slohova praca.
Skratky ale v podstate neznasam. Neznasal som ich uz od cias ked som robil v C++ a v jave mi tento system vyhovuje. Takto aj ked je kod zlozity, umoznuje mi to lepsie sa zorientovat a nehadat co tam ta jedno-dvoj pismenkova skratka znamena. To vzdy trepem o hlavu juniorovi a dost rad im robim zle v tej forme, ze sa o pol roka po implementacii spytam co ten kod robi a aby sa rychlo zorientovali. Samozrejem ze sami nevedia co to znamena a trapia sa s vlastnym pomenovanim. Ale casom sa naucia kodit rozumne, ze sa v tom vyznam aj ja.
-
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.
-
Filip JirsákStříbrný podporovatelTy 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
xsjsem to ani nedokázal dekódovat.xnaprosto 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.
-
Filip JirsákStříbrný podporovatel
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
xtak č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í.
-
Filip JirsákStříbrný podporovatel
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? -
Filip JirsákStříbrný podporovatel
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: childSnad vám to pomůže. Jinak samozřejmě můžete trollit dál.
-
Filip JirsákStříbrný podporovatel
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.
-
Filip JirsákStříbrný podporovatel
Protože vycházím ze zkušenosti, že kratší kód se čte lépe.
To ovšem zcela zjevně není pravda. A přijdete na to jistě sám, když se nad tím zamyslíte. -
> kdy na vyvíjené aplikaci pracuje více než jeden člověk najednou, a navíc se tato aplikace bude vyvíjet dalších řekněme 20 let
Tak ono úplně stačí, když se k tomu vrátí stejný člověk po pár letech. Ty zkratky, co jsem tehdy vymyslel, mozek udržel v hlavě maximálně pár měsíců...
Tenhle dobrý zvyk (pojmenovávání plnými slovy) jsem si pak naštěstí přenesl i do jiných jazyků.
-
Tak zrovna věci jako "var csvImportOrderService = new CsvImportOrderService();" mi přijdou na první pohled podezřelé.
Proč říká jméno proměnné to samé, co jméno typu? Typ mi umí zobrazit i IDE. Kdyby se to jmenovalo "something" tak jako čtenář kódu vím to samé (pokud to nebudu editovat v notepadu).
To o tom objektu opravdu nemáme žádné další užitečné informace, kterýma by se některé z těch redundantních slov dalo nahradit?
-
No uz iba ze by ste to cital napriklad na GitHub-e alebo hocikde inde mimo IDE ze? Preco sa mame spoliehat na IDE? Staci to normalne pomenovat v danom kontexte aby to bolo zrozumitelne. Naviac IDE vam pri PISANI toho kodu dost pomoze aj s nazvami premennych. Znova: "1x piseme 100x citame".
Vo vasom priklade sa myslim nic nestane ak tu premennu nazvem napriklad "csvImport", vzdy lepsie ako cio. -
> Naviac IDE vam pri PISANI toho kodu dost pomoze aj s nazvami premennych. Znova: "1x piseme 100x citame".
Vo vasom priklade sa myslim nic nestane ak tu premennu nazvem napriklad "csvImport", vzdy lepsie ako cio.Tak na přesně tohle jsem narážel. Ano, tyhle ukecané názvy se velice jednoduše píšou, protože to IDE udělá za vás. Akorát to pak někdo bude muset 100x přečíst, jen aby se dověděl, že se nic nového nedozvěděl.
-
No to se pravděpodobně neshodneme. Nějaký CsvImportOrderService by se imo měl v nějakém velmi omezeném kontextu vytvořit, nakonfigurovat a pro zbytek programu by měl být schovaný za nějakým obecnějším rozhraním.
Takže v kontextu, kde má smysl existence nějaké proměnné typu "CsvImportOrderService" je i to naprosto stupidní "cio" lepší název.
-
Jo, ten "csvImport" je lepší než plný název, proti kterému jsem se vymezoval. Akorát bych dodal, že skoro všechno je lepší než ten plný název. Vlastně každé slovo z toho typu by mohlo stačit.
Když mi IDE nabídne 2-3 názvy, tak nemá žádné další info. Jen ten typ, co jsem napsal. Takže pokud tam nechci napsat nějaké dodatečné info já, tak dává smysl brát primárně tu nejkratší nabízenou možnost. Když už se čtenář nic nového nedozví, tak ať toho aspoň nemusí číst moc.
-
Filip JirsákStříbrný podporovatel
Proč říká jméno proměnné to samé, co jméno typu?
Pokud je to jedináček, nebo se v daném kontextu používá jenom jednou, pak je celkem logické, že se instance jmenuje stejně, jako třída, protože ta instance dělá přesně to samé, jako třída. A v daném kódu se to musí vyskytovat dvakrát jednoduše proto, že daný programovací jazyk nemá speciální podporu pro jedináčky nebo vytváření objektů bez tříd, ale simuluje se to pomocí běžných tříd.Jo, ten "csvImport" je lepší než plný název, proti kterému jsem se vymezoval. Akorát bych dodal, že skoro všechno je lepší než ten plný název. Vlastně každé slovo z toho typu by mohlo stačit.
Nedá se to říct takhle obecně, záleží na kontextu. Respektive obecně by se dalo říct jenom to, že ten plný název je lepší, než cokoli jiného. Pokud jste v kontextu, kde se řeší jen import objednávek z CSV, můžete to nazvat třebaimportService, nebo dokonce jenservice. Nazvat to jenomcsvImportbude špatně prakticky vždy, protože tam, kde s touto instancí služby budete pracovat, budete pracovat nejspíš i s daty. A zcsvImportpak nepoznáte, zda je tam služba nebo data.Takže pokud tam nechci napsat nějaké dodatečné info já, tak dává smysl brát primárně tu nejkratší nabízenou možnost. Když už se čtenář nic nového nedozví, tak ať toho aspoň nemusí číst moc.
Název neslouží jen k tomu, aby se z něj čtenář něco nového dozvídal, ale také k tomu, aby od sebe odlišil různé objekty.Argument „aby toho čtenář nemusel číst moc“ je úplně mimo a svědčí to jen o absolutní neznalosti toho, jak lidé vnímají informace. Podívejte se na lidský jazyk, kolik je tam redundance – všechna česká slova byste s obrovskou rezervou nacpal do čtyřpísmenných slov, přitom průměrná délka českého slova je 5 znaků a jsou slova mnohem delší. S hláskami to je v zásadě stejné. Nemyslíte si, že by se za ty desítky tisíc let evoluce jazyků vyvinul úspornější jazyk, kdyby to z hlediska lidského vnímání dávalo smysl?
Lidé, kteří umí číst, nečtou slova po písmenkách, čtou je jako obrázky – jako celek nebo po větších částech. Delší název (třeba
csvImportOrderService) tedy čtení neztěžuje, naopak ho usnadňuje, protože takový název bude typicky výrazně odlišný od jiných názvů ve stejném kontextu. -
Já bych teda byl hodně opatrný s paralelama mezi programováním a přirozeným jazykem. Je to "csvImportOrderService" slovo, nebo sousloví?
Protože třeba opakování stejných sousloví nebo frází znova a znova se v přirozeném jazyce snažíme hodně vyhýbat. A jestli slovo, tak takhle složitá slova používají běžně snad jenom němci. A takoví francouzi vám snad udělají i zkratku z delší zkratky.Vemte si, že kdybych měl v textu několikrát napsat třeba "Filip Jirsák", tak místo toho automaticky sáhnu po jednom z nejkratších slov "on". I při psaní slohu mi vtloukali do hlavy, ať se pokud možno neopakuju. Většina smluv na prvních stránkách definuje nějaké zkrácené identifikátory, které se používají ve zbytku textu.
-
Filip JirsákStříbrný podporovatel
To neopakování stejných slov ale platí pro publicistiku a beletrii a je to pro to, aby text byl zajímavější. V odborných textech se naopak slova záměrně opakují, protože když pro něco zavedete termín, používáte pořád ten jeden termín. Zdrojový kód počítačového programu nemá být zajímavý a čtivý, má být čitelný a přesný. Ty smlouvy nedefinují zkrácené identifikátory zkratkami a rozhodně je nedefinují tak, aby mohlo dojít k jejich záměně.
-
peci1Stříbrný podporovatelJeste mam pocit, ze na to, jak dlouhy nazev vyvojar vymysli, ma vliv omezeni na delku radku. Pokud nejaky nestastlivec stale zalamuje na 80 znacich, tak asi nebude rad vymyslet nazev, ktery ma 50 znaku. Ja si ve svych projektech zalamuju na 120 a je to o dost mensi problem... Ale nechci tady spoustet flame war :)
-
Omezení délky řádků má rozhodně i další důvody, než jen technické omezení terminálu. Ve vašem případě poněkud začínám chápat, odkud vítr vane. Ano, zdrojových kódů roztažených někam za obzor se zaručeně dokonale popisnými názvy všeho, jehož celková přehlednost a tím i spravovatelnost se stejnou měrou blížila nule jsem už viděl za svou praxi dost.
-
Absolútne nesúhlasím. Identifikátory by mali byť vždy 1 až maximálne 3 slová dlhé. Nikdy nie viac. A snake_case, nie camelCase. Existuje aj odborný článok a reálne merania jak dlho trvá čítať a porozumieť kódu, ktorý je písaný určitým spôsobom. A rozhodne desať slovné identifikátory v camelCase, nebodaj so skratkou, kde viacero písmen za sebou sú veľké, to čitateľnosť a rýchlosť pochopenia kódu len znižuje.
-
No suhlasit nemusite ale to je houby platne. Ziadny snake_case na premenne, max na konstanty. Java ma na to odporucanie priamo v definicii jazyka:
https://www.oracle.com/java/technologies/javase/codeconventions-namingconventions.html -
Ak je tym dovodom to ze nechcete kod pisat tak aby tomu ostatni v teame rozumeli tak je to arogancia z vasej strany. Kludne to nepouzivajte s tym problem nemam.
Existuje milion dalsich pravidiel ktore si firmy stanovuju ako kriteria kvality odovzdavaneho kodu. Menna konvencia je absolutny zaklad a clovek potom vyzera velmi neprofesionalne. -
Vaše úvaha je elementárně chybná už tím, že ji celou zakládáte na předpokladu, že jinak tomu ostatní lidé z týmu nerozumí. Jenomže oni tomu rozumí a to, co tu vykládáte jsou vaše hypotézy a dojmy, to je celé.
Jmenná konvence je základ. A já a nejen já tvrdíme, že ta, co se používá zhusta v Javě, zvlášť ta, co v ní používají někteří vývojáří mající stejně sebestředný jako hloupý dojem, dojem, že jsou pánibozi, je často buď špatně sama o sobě, nebo některými naprosto špatně uchopená. A o to více se pak často titíž bijí za to, že je to je jediná správná zjevená pravda.
-
Vidim ze mate z java programatorov nejaky komplex. Trvat na mennej konvencii nie je bozsky komplex. :-D
Je to menna konvencia podla ktorej sa pise kod. Nie je firemne zavisla ani zavisla na programatorovi. Je zauzivana v celej komunite. Potom ked si pozerate cudzie kniznice alebo kod tak sa vam nekrizia oci. -
Filip JirsákStříbrný podporovatel
martipoljak: Zatím jediný, kdo tu má sebestředný a hloupý dojem, že je pánbůh, jste tu vy. Napadáte tu jiné lidi a ještě tak obecně, že se to dá vztáhnout na každého i na nikoho. Přitom samotné vaše tvrzení je vnitřně rozporné a vypadá to, jako byste vůbec nevěděl, o čem píšete.
A já a nejen já tvrdíme, že ta, co se používá zhusta v Javě, zvlášť ta, co v ní používají někteří vývojáři
V první větě tvrdíte, že je nějaká jedna konvence používaná zhusta v Javě, za čárkou pokračujete tím, že z té jedné konvence lze zvlášť vyčlenit ještě jinou konvenci. Takže jste z jednoprvkové množiny vyčlenil jednoprvkovou podmnožinu, vedle které zůstala ještě jiná podmnožina, která je neprázdná. není to trochu zvláštní?A celkově je váš komentář o tom, že jste obvinil nějaké vývojáře (neřekl jste, které) z používání nějaké konvence (neřekl jste jaké), ve které je něco špatně (nenapsal jste co). Takové univerzální hejtovací tvrzení, ve kterém není jediná věc, která by se dala ověřit nebo rozporovat. Prostě buď někdo má rád váš ničím nepodložený hejt a olajkuje vám to, a ostatní si řeknou „sakra co to je, vždyť nenapsal jedinou konkrétní věc“ a poklepou si na čelo.
-
Právě kvůli takovým zkratkovktým radám tu trollové jako @Filip Jirsák rozjíždějí svou zábavu.
U kódu se musí přemýšlet.
Všimněte si, že třeba @Dushino42 toto přesně nedělá.
Je-li symbol krátký, je to extrémní výhoda, protože to pomáhá čitelnosti.
Jenže jsou situace, kdy vhodný název pomůže, i kdyby byl delší. Například když smlouvu přiřazujete tak použijete názvy jako "payer", "recipient", "accountant", protože je to zrovna ta informace, která vás zajímá. Žádné typy, že je to kolekce, nebo podobné smetí tam nechcete vidět. I kdyby vám to IDE strašně rychle generovalo. -
Filip JirsákStříbrný podporovatel
Je-li symbol krátký, je to extrémní výhoda, protože to pomáhá čitelnosti.
Právě naopak, krátké symboly čitelnost zhoršují.Žádné typy, že je to kolekce, nebo podobné smetí tam nechcete vidět.
Programátoři to vidět chtějí. Protože to pomáhá srozumitelnosti. A zrovna přidání „s“ nakonec pro označení množného čísla fakt není něco, co by název výrazně prodloužilo. -
Filip JirsákStříbrný podporovatel
Mají pocit, že jim to pomáhá srozumitelnosti.
Zkušenost je taková, že to srozumitelnosti pomáhá. A dá se i poměrně snadno vysvětit, proč to pomáhá. A na rozdíl od vaší „zkušenosti“ to nejde vyvrátit pár triviálními protipříklady. -
Filip JirsákStříbrný podporovatel
Vy jste snad v předchozím komentáři něco uvedl? Takže gratuluju k sebekritice, že jste založil zbytečné vlákno.
-
Možná jste nepostřehl, že to rčení má v sobě pochopitelně jistou míru nadsázky, ale dobrý, rozčilujete se pěkně. Protože stejně jako jakékoliv jiné podobné rčení ukazuje i druhou stranu mince.
Jestli něco slouží jako filtr nebo neslouží netuším, v Javě jsem naposledy psal na vysoké škole a není to něco, co by mě bavilo natolik, abych to chtěl dělat profesionálně jakkoliv jsem k tomu byl tu a tan okolnostmi donucen. Takže to je další zjevný nesmysl některých nafoukaných javových programátorů, co mají dojem, že jsou dobří programátoři, abych na to rčení navázal :-D
-
Jsou věci které mě baví takovým způsobem, že je chci dělat profesionálně a jsou věci, které mě baví takovým způsobem, že je nechci dělat profesionálně. Java patří do té druhé kategorie. Bavila mě, ale dělat bych v ní nechtěl. Na tom není nic divného.
A ne, to rčení není nesmysl. Ale chápu, že se vás osobně dotklo. Proč? To zase naopak může vypovídat třeba o vás, ne? Ostatně já jsem ho nevymyslel.
-
To ze vam niekto povie blbost neznamena ze si ju musite adoptovat za svoju a opakovat ju.
Ja vam nevycitam ze vas nebavi (ako som uz napisal hore). Ale za vas nebavi z hlupych dovodov (ako som uz pisal hore).
Ak podla vas rozhoduje o tom kto je dobry programator jazyk v ktorom pise to je to iste ako keby ste tvrdili ze inteligentny clovek moze hovorit iba po anglicky. Je to nezmysel ale obavam sa ze to opat nepochopite. -
To, co je pro vás hloupé je třeba pro někoho jiného důležité. A jsme u té arogance, že, co jste kdesi zminil. Nemluvě o tom, že vaše schopnost chápat nadsázku se evidentně limitně blíží nule. Doufám, že takhle nepracujete s každým příslovím, rčením nebo vtipem, které slyšíte. Pokud ano, o dost se připravujete protože všechny z nich kromě nadsázky také ukazují na něco, co není dobře vidět. Vzhledem k tomu, co píšete a jisté slepotě ve vašich vývodech by mě to moc nepřekvapilo.
-
No tak do Javy a Javistů se v tomhle strefuje velmi dobře. Přece jenom Gosling v nějakém rozhovoru dost natvrdo řekl, že navrhoval Javu pro programátory, kteří pořádně nechápou ani uint.
Že je to v nějakém korporátním průtokovém ohřívači juniorů i docela rozumný předpoklad je jiná (a trochu smutná) věc.
-
To rozhodně ne. Ale Java má prostě pověst jazyka ve kterém nějaká "lopata" nenapáchá moc velké škody. Nebo by teoreticky neměla ;)
A pak tu máme pár korporátů známých tím, že každý nový programátor musí být do určité doby povýšen, nebo vyhozen. Takže ty kódy píšou junioři a pak přejdou na řízení nových juniorů a kód už moc nepíšou. -
Filip JirsákStříbrný podporovatel
Java má prostě pověst jazyka ve kterém nějaká "lopata" nenapáchá moc velké škody. Nebo by teoreticky neměla ;)
Což je správně, to drtivá většina lidí chce. Nástroj, který by mohl zabránit páchání škod, ale neudělá to, totiž nedává moc velký smysl. Ve výjimečných případech se takový nástroj může hodit, když to rozpoznávání páchání škod selže. Ale jsou to výjimečné případy, pro které se hodí mít takový nástroj schovaný někde vzadu v šuplíku a mít někoho, kdo ho umí použít. Ale nepotřebujete, aby s takovým nástrojem pracovali všichni každý den.Ona to není náhoda, že oblibu získávají jazyka jako Rust nebo Go, dříve ji získaly Java, Python, JavaScript – všechno jsou to jazyky, které se snaží bránit tomu, aby někdo neznalý nenapáchal moc velké škody. Pokud byste chtěl argumentovat tím, že opravdoví programátoři píšou v C nebo C++, nezapomeňte, že i C a C++ vzniklo proto, aby programátoři páchali méně škod, než v assembleru.
-
Tak hlavni duvod existence Java hateru je prosty fakt, ze o Jave vi hovno.
Hlava mi nebere, kde bere chlap, co videl javu pred lety na skole, presvedceni, ze o tom vubec neco tusi.
Realita je krapet jina.
Samotna Java je jenom dilek ekosystemu.
Zato kombo Java 17 + maven (gradle etc..) + Maven central + Spring boot + Apache foundation + IntelliJ (nyni nove i VSCode s java extenzi od RedHatu) je sila, ktera nema obdoby.Python je lepsi jenom na rychle jednorazove udelatka, golang je lepsi na lehke microservicy s rychlym startem, rust a C na lowlevel.
A popravde jediny mainstream jazyk, ktery je nyni svymi moznostmi lepsi nez Java, je Typescript, hlavne kvuli null problemu Javy. A to proto, ze Javu (tedy spis C#) komplet opjacoval a pridal par peknych veci navrch.
Python taky Javu mocne pajcuje, uvadi anotace(dekoratory), type hinty. Stylem rovnaku na ohybaky.
Vzdyzky kdyz na webu vidim blaboleni, ze whatever jazyk je lepsi jez java, protoze umoznuje napsat "Hello World" na jeden radek, hned vim, ze mam pred sebou idiota. Jeste jsem nevidel, ze by nekdo nekomu zaplatil za to, ze mu napise Hello World.
Pak mame v takovem "jednoduchem" jazyce praseciny typu
"if __name__ == '__main__':",nebo hruzy typu:
class BlaBla
def __init__(self,x)
self.__x = x -
Tohle bude trochu samonaplňuící se proroctví. Samozřejmě že někdo, kdo nerad Javu (z libovolného důvodu) v ní nebude moc dělat a nebude toho zas tolik vědět.
Prasečiny se samozřejmě jazyk od jazyka liší. Z typických Javovských prasečinek si střílí třeba Fizz Buzz Enterprise.
No a pak je tu taky ten drobný problém, že OOP v Pythonu je úplně jiné paradigma než OOP v Javě. :)
-
Samotna Java je jenom dilek ekosystemu.
Zato kombo Java 17 + maven (gradle etc..) + Maven central + Spring boot + Apache foundation + IntelliJ (nyni nove i VSCode s java extenzi od RedHatu) je sila, ktera nema obdoby.Vytesat do kamena !
Pracujem ako technology architekt, lead vyvojar a team leader, robim code review, workshopy, mam pod sebou niekedy az desiatky vyvojarov.... vzdy, ked citam diskusie ohladom Javy, ale aj inych jazykov, tak mam pocit, ze v diskusii su maximalne tak akademicke reci ludi, o ktorych odbornosti resp. pouzitelnosti v praxi mozeme polemizovat...cest vynimkam, ktorych sa tu par najde - no offense.
Ako bolo napisane...v enterprise rieseniach je ekosystem Javy a frameworky absolutne neporazitelny (nebavime sa o mission critical a low level systemoch). Ci mame aj v inych jazykoch C++, Rust, Python frameworky ako Spring, Micronaunts, Quarkus... Ci si myslite, ze pri vyvoji microservice je dolezity jazyk a jeho vyrecnost alebo to, aku mam podporu pri implementacii Event Soucingu, DDD paradigmy, service discovery, telemetry, tracovaniu a pod.? Pre ekosystem Javy prakticky neexistuje pri vyvoji novodobych enterprise rieseniach, ci uz klasickej 3-vrstvovej architektury alebo novodobych microservice architekturach. Toto proste nepochopia ludia, ktory s tym aj v reale nepracuju, ktory nikdy nerobili architekturu enterprise riesenia, scaffolding a netvorili technologicky stack - rozmyslam, co by som tuto robil s Pythonom alebo Rustom - nech su to akokolvek dobre jazyky. Dokonca ani C# sa ekosystemom nechyta, hoci ma novsiu a lepsiu syntax jazyka ako Java.
Co ma ale zaraza, su veci, ktore sa tu riesia v praxi a enterprise je to uplne o niecom inom. V skutocnom svete riesime kolaboraciu pri vyvoji, kde je daleko viac dolezita struktura kodu, obecna spravnost, citatelnost, zrozumitelnost a UDRZATELNOST... dobry programator sa nepozna podla jazyka, ale podla toho, ako rozumie a ako aplikuje architektonicke a navrhove vzory a pod.
-
>> jediny mainstream jazyk, ktery je nyni svymi moznostmi lepsi nez Java, je Typescript, hlavne kvuli null problemu Javy.
To snad nemůže být myšleno vážně. Znám Javu i TS. To se přece vůbec nedá takhle porovnávat, TS je virtuální, abstraktní jazyk, který je uvnitř stejně jen "základní" JS, nejen (a hlavně) co se týče typů. TS má nejen stejné "problémy" s null, ale díky JS má i stovku jiných problémů, které Java nemá. A to dodávám, že nejsem extra fanoušek OOP, takže ani Javy. Ale radši bych volil Javu, než se muset brodit neustále jen TypeScriptem a pitomým prostředím nutné transpilace z TS do JS.
-
Ono o tom hovoril aj Uncle Bob (Robert Cecil Martin) - v podstate vravel že už nie sme v 70-tych rokoch kde počítame každý charakter na monitore a všetko píšeme ručne. Máme ultra-wide monitory a IDE ktoré nám pomáhajú pri písaní. Tak to využívajme a urobme kód čo najzrozumiteľnejší. Samozrejme to nepreháňajme ale nebojme sa mať dlhé popisné mená tried.
U premenných to záleží od kontextu - ak má trieda 3 riadky tak je zrejme jasné čo robí premenná 'x'. Ak je ale metóda dlhá a zložitá, pomenujme premenné popisne -
Už na základní škole se ve slohu učí, že to, že je něco dlouhé ještě opravdu nezbnamená, že je to srozumitelné. Ono by se to asi mělo učit i na vysoké vzhledem k tomu, že od té základky to podle kvality jejich výstupů tak 80 % lidí zase zapomene.
A ne, hlavně se, proboha, nevymlouvejme na příšerné široké monitory (co si je spousta vývojářů radší otáčí na výšku) nebo IDE (já vím, ať žije IDE-driven development).
-
Jenže ve slohu se jedná o souvětí. Ve slohu je souvětí o větě hlavní a jedné či dvou větách vedlejších uplně běžná a věc, která je považovaná za srozumitelnou. Takže podle vaší logiky by stejně dlouhej název třídy, nebo metody, či proměnné, byl v pohodě. Ale pro mě už je takovejdle naming dost za hranou.
Vaše argumenty jsou uplně mimo mísu. Čtete tu daleko delší komentáře (a i článek), ale pka vám dělá problém si přečíst popisnější jméno metody, či proměnné?
Mnoho zasloužilých vývojářů, autorů kompilátorů či populárních knihoven, definuje čistý kód tak, že se čte jako kniha/báseň.
Pokud někdo pojmenovává proměnní, třídy, a další tak, že z názvu nepochopim, co dělaj, musim začít zkoumat kód, což zdržuje. Samozřejmě jsem schopnej pochopit, co danej kód dělá, ale radši si přečtu během delší název, než minutu zkoumat, co se vlastně v dané proměnné nachází, co ta metoda teda přesně dělá, atd.
-
Filip JirsákStříbrný podporovatel
To, že když z něčeho uděláte zkratky, bude to hůře srozumitelné, se ve slohu ani neučí, protože je to všem zřejmé.
V zápisku nebylo napsáno nic o tom, že čím delší název, tím lepší. Zápisek byl zaměřen proti nicneříkajícím krátkým názvům, protože se bohužel stále vyskytují jedinci, kteří si myslí, že co nejkratší názvy jsou dobře.
IDE není žádná výmluva, IDE je nástroj, který drtivé většině programátorů výrazně usnadňuje práci. Nikdo, kdo chce být ve své práci dobrý, nezahazuje věci, které mu umožní být ještě lepší. (Ponechme stranou lidi, kteří čtyři dny malují schémata na papír a pak napíšou čtyřicet řádků kódu, ke kterému se dalších třicet let bojí celý tým jen přiblížit. Takových je (potřeba) malinko a ti si zase nebudou ta schémata malovat propiskou, která každou chvíli přestane psát.)
-
Kdysi dávno, pradávno, jsem narazil s proměnnou "hy", ke které jaksi
nebyl vysvětlující komentář
. Odpověď pachatele na tuto výtku zněla, žeje to sice zkrácené, ale samopopisné
- ta proměnná označovala opakovaný průchod větví programu.
Pro nedůvtipné a začínající: šlo o zkráceninu zhymen
a všem bylo hned jasné, že se z prvotníhotrue
každým průchodem nastaví nafalse
. ;o)
(Poznámka: napsání tohoto příspěvku trvalo cca 1 minutu, kontrola a odeslání cca 10 minut s pomocí kolegy, který mi pomohl překonat zlotřilou funkciNejsem robot
. Opravdu je to tady tak nutné? Pro přihlášené diskutující?
Proč nemůžeme přispívat i my, roboti?) -
Filip JirsákStříbrný podporovatel
Je zajímavé, jak mají někteří potřebu bránit se fanatikům, kteří propagují názvy přes půl fotbalového hřiště – přitom se takoví fanatici nikde nevyskytují.
-
S autorem souhlasim, jenom dolnim dulezite, co nezaznelo.
U javy je pri cteni dulezity syntax highlighting.Koder si po chvili zvykne na barevne odliseni a pri cteni bloku kodu ty dlouhe nazvy ani necte cele, jenom podvedome rozlisuje tvar.
Cely nazev si precte jenom poprve a potom vzdy, kdy si musi pripomenou vyznam daneho variablu.Cist Java kod bez syntax highlightingu je velice unavne a otravne.
Ostatne i psani tech dlouhych popisnych nazvu je bez IDE otravne, s IDE se napise jednou a pak CTRL + .Vyhodou je, ze takto dobre napsany kod pochopi i neprogramator, ktery chape "if", "loop", variable scope, try/chatch/exception.
-
Josef MarianekBronzový podporovatel
Za me nesouhlas. Nazvy jako ExternalOrderService 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čí.
-
Filip JirsákStříbrný podporovatel
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 ExternalOrderService nebo ExtendedOrderService 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). -
Josef MarianekBronzový podporovatel
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. -
Filip JirsákStříbrný podporovatel
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 ExternalOrderService 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.
-
Filip JirsákStříbrný podporovatel
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 ExternalOrderService. 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. -
Filip JirsákStříbrný podporovatel
Ono na vyřazení IDE úplně stačí zkrátit to jen na
ExternalOrderSvca pak napsat naprosto běžnéExOrSeneboEOSe. 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 toSvcneboService. -
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: StationIDoi byste navrhoval? `TransAnal`?
-
-
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
-
RaviseStříbrný podporovatel
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í
CsvImportOrderServiceje 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 prefixcsv_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
bufafile_like_string_buffernení žá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
CSVImportOrderServicezaJSONImportOrderServicetypicky vyžaduje úpravu konstruktoru (přinejmenším v tom smyslu, že už tam nemůžu posílat původní"orders.csv"). -
Filip JirsákStříbrný podporovatel
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.
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). -
-
Filip JirsákStříbrný podporovatel
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. -
RaviseStříbrný podporovatel
> 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_BUY_ALCOHOLa najednou to prokoukne, že? -
Filip JirsákStříbrný podporovatel
Jo, tohle miluju. Řve na mne z kódu konstanta psaná kapitálkami, a ještě místo magické osmnáctky, o které každý ví, co znamená, musím luštit význam daleko magičtější konstanty. Ne, neprokoukne to – je to daleko míň čitelné, protože musím pokaždé zjišťovat, co v té magické konstantě vlastně je za číslo.
-
A když budete ten soft chtít upravit pro stát, který má jiný věkový limit pro alkohol, tak uděláte co? Budete fulltextově hledat "18"? A pak luštit, jestli tahle 18 je limit pro chlast, nebo třeba limit pro svatbu nebo řidičák?
Co je v té konstantě za číslo máte přece v jejím názvu. Najednou vám dlouhé samopopisné názvy vadí?
-
Filip JirsákStříbrný podporovatel
Když ten limit bude na jediném místě v kódu, nemusím nic hledat fulltextem. Pokud má na spoustě míst kódu zduplikovaný kód zjišťující, zda můžu dotyčnému prodat alkohol, je špatně to, že je ten kód napsaný několikrát, místo toho, aby to byla jedna funkce, která se volá z více míst.
Vadí mi samoúčelné ukládání hodnoty do proměnné, když se ta proměnná použije jenom jednou a její název má menší informační hodnotu, než uvedení hodnoty samotné. Je jasné, že tohle se těžko rozhoduje a závisí to na konkrétním týmu – pokud to bude český tým, bude pravděpodobně každému jasné, co znamená 18, a bude to pro ně zřetelnější, než když to bude v proměnné. Pokud by to byl mezinárodní tým, bude potřeba tam dát tu proměnnou, protože pro lidi z toho týmu by to bylo magic number.
U toho pravidla o ukládání magic number do konstant je důležité to, že se to netýká všech čísel, ale jenom magických čísel – tedy takových čísel, u kterých není zřejmé, kde se vzala.
-
> Když ten limit bude na jediném místě v kódu, nemusím nic hledat fulltextem.
To ale netuším, dokud ten fulltext search neudělám. Ani jednomužný hobby projektík neudržím celý v hlavě, natož něco většího.
Když je to pojmenovaný symbol, tak si v IDE ty jednotlivá použití můžu jednoduše projít. Ale s hledáním nejakého čísla mi IDE moc nepomůže.
-
Filip JirsákStříbrný podporovatel
Když je to pojmenovaný symbol, tak si v IDE ty jednotlivá použití můžu jednoduše projít. Ale s hledáním nejakého čísla mi IDE moc nepomůže.
Začal jste od prostředka. Když to budou pojmenované symboly, budete muset nejprve fulltextem vyhledat všechny výskyty čísla 18, zjistit, do jakých pojmenovaných symbolů se ukládají – a pak teprve můžete hledat v IDE použití těch symbolů.Pokud byste náhodou chtěl argumentovat tím, že ten pojmenovaný symbol má být v projektu jenom jeden – máte pravdu, ale přemýšlejte o tom, jak se to stane, aby byl jenom jeden. Někdo bude chtít tu hodnotu použít, tak prohledá fulltextem projekt, zda už náhodou někde není ten symbol definován. Nebo jestli se to náhodou někde nepoužívá přímo v kódu. Když najde pojmenovanou konstantu, buď ji použije, nebo kód refaktoruje, aby ji mohl použít. Když najde přímo číslo, zrefaktoruje kód tak, aby třeba vytkl metodu, kde se ta to číslo používá (protože ho bude chtít použít stejným způsobem, takže nebude kód kopírovat).
Nebo-li postup vývojáře bude pořád stejný, ať to bude pojmenovaný symbol nebo přímo číslo v kódu.
Jak už jsem psal, ten věk je zrovna hraniční případ a záleží na týmu, někde bych považoval za správné ten pojmenovaný symbol vytvořit, někde by mi přišlo lepší mít to přímo v kódu, pokud to bude jen na jednom místě. Ale jsou i jasné případy, kdy nemá smysl vytvářet pro to konstantu. Pokud budu mít v aplikaci výpočet plochy čtverce, nebudu tu dvojku označující mocninu dvou nikam dávat jako konstantu. Protože to není žádné magické číslo ale je to prostě číslo, jehož význam každý pochopí daleko snáz, než kdybych se pokoušel uložit to do pojmenovaného symbolu.
-
RaviseStříbrný podporovatel
> Řve na mne z kódu konstanta psaná kapitálkami
Verzálkami.
> o které každý ví, co znamená
Stačí jeden cizinec v týmu a jste v pytli.
> magičtější konstanty
raise WTFError. To jméno je doslova popisek toho, co se pod tím symbolem skrývá.
> protože musím pokaždé zjišťovat, co v té magické konstantě vlastně je za číslo
Proč?
-
Filip JirsákStříbrný podporovatel
Verzálkami.
Ano, když na mne někdo řve, jsem z toho tak zmatený, že si pletu verzálky s kapitálkami. Možná kdyby konstanty zapsané verzálkami IDE zobrazovalo kapitálkami, byl bych k nim smířlivější.Stačí jeden cizinec v týmu a jste v pytli.
To jsem už řešil v předchozím komentáři.To jméno je doslova popisek toho, co se pod tím symbolem skrývá.
Pokud myslíte toMIN_AGE_TO_BUY_ALCOHOL, pak není. Vztahuje se to na ČR? Co když je to konstanta dotažená z nějaké knihovny, která to má třeba podle USA?Proč?
Proto, abych si ověřil, že je tam to, co potřebuju.Vždycky mne fascinuje, když je na začátku třídy
private static finalkonstanta psaná VERZÁLKAMI, aby se pak použila v jediném místě v kódu. Takže když na použití narazím, musím odskočit na její deklaraci, tam zjistím její hodnotu, a zase se vrátím zpět. Proč má ta konstanta zamořovat scope celé třídy, když je použitá v jedné metodě? Protože je to uřvaná konstanta psaná verzálkami, tak může? Kdyby si takhle někdo vytáhl z metody do celé třídy proměnnou, tak si bude každý klepat na čelo. No jo, jenže kdybych tu konstantu přesunul do metody před místo, kde se používá, už by to nebyla TA konstanta a leckdo by se mohl ptát, jestli to na to jedno použití opravdu musím pojmenovávat, když se z toho jména dozvím méně, než ze samotné hodnoty.Znovu opakuju, že ten věk jako hranice pro prodej alkoholu je hraniční případ. V jednom týmu mohou všichni bezpečně vědět, co je 18 v souvislosti s alkoholem, a
MIN_AGE_TO_BUY_ALCOHOL_IN_CZECHIAnemá žádnou přidanou hodnotu. A jsou týmy, kde to třeba jeden cizinec vědět nebude a je dobré tam doplnit komentář, nebo týmy, kde to nebude vědět skoro nikdo a má smysl to číslo pojmenovat. Nakonec je ale stejně nejlepší pojmenovat tu podmínku (udělat z ní funkci). -
Filip JirsákStříbrný podporovatel
Ne, tohle je velmi špatné řešení. Když to nechcete vidět v IDE rovnou, ale až v nějakém informačním okně, stačí ta definice hodnoty. Rozumné IDE vám tu hodnotu v rychlé nápovědě zobrazí a nepotřebuje k tomu JavaDoc. Pokud vám to IDE nezobrazuje, doporučuju změnit IDE.
Ten JavaDoc je špatně, protože vám neříká nic víc, než co vidíte v kódu. A navíc může být špatně – někdo změní v kódu konstantu na 21, ale v JavaDocu zůstane 18.
-
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?
Tohle je špatný příklad. Kdyby tam to csv nebylo, tak bych předpokládal, že typ toho order bude jen nějaký interface jakoImportOrderServicea pak dává smysl proměnnou pojmenovat jakoimport_order_service. Tím odebránímcsvjsi ztratil důležitou informaci a v případě, že budeš mít ještě typyXmlimportOrderService, 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
-
RaviseStříbrný podporovatel
Osobně vidím stejné dilema, jenže obráceně: proč je pro mě podstatné, že je to zrovna
CSVImportOrderService? Všechny věci, které jsou procsvspecifické za mě řeší ta třída (od toho přeci je), a tam, kde se držím rozhraní, zase nezáleží, jestli je implementacícsvnebosqlite(ať se neopakujeme :))Nehledě na to, že pokud mi ta služba přiteče parametrem, tak ten bude stejně skoro vždycky typu
ImportOrderServiceInterface. 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 instanciCSVImportOrderServiceneboXLSXImportOrderService.Jediné místo, které je opravdu specifické pro
csvbude 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 budeswitcha příští měsícImportOrderServiceFactory. -
Filip JirsákStříbrný podporovatel
proč je pro mě podstatné, že je to zrovna CSVImportOrderService? 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 ImportOrderServiceInterface.
Nebo také bude typuCSVImportOrderService. 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, jestliimportOrderServicejeCsvImportOrderService, 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 CSVImportOrderService. 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 CSVImportOrderService 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é CSVImportOdrderService a NecoImportOrderService, 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 "csvImportOrderService". Merge takového commitu může být sranda.
-
RaviseStříbrný podporovatel
> 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é).
-
Filip JirsákStříbrný podporovatel
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é).
Pokud to správně chápu, každá informace, která se dá odvodit z kontextu, je podle vás zbytečná.Jenže tak to právě není. Zdrojový kód je způsob komunikace programátora s počítačem a zároveň s jinými programátory. Zda komunikace funguje správně s počítačem je relativně snadné ověřit testy – relativně vůči tomu, jak nesnadné je to ověřit u lidí. Komunikace programátor–programátor je ale velmi náchylná k chybám, ke kterým může docházet na obou stranách. Stejně jako u běžné mezilidské komunikace. To, že se používá formalizovaný jazyk, je výhoda i nevýhoda – výhoda je v tom, že se odstraní většina problémů plynoucí z nepochopení syntaxe sdělení, nevýhoda v tom, že ten jazyk je záměrně vzdálen reálnému světu, který má popisovat.
Aby si lidé vůbec rozuměli, přidává se do jejich komunikace spousta redundance. A to platí pro komunikaci v přirozeném jazyce i v komunikaci ve formálním programovacím jazyce – protože v obou případech se bavíme o popisu reálného světa. Ta redundance je tam za třech důvodů. Za prvé mluvčí může znát některé kontextové informace, které adresát nezná. Proto je lepší, když je uvede ve sdělení. Za druhé, běžně se stává, že nějakou věc pochopí mluvčí a posluchač jinak. Pokud pak ta samá informace zazní ještě jednou trochu jinak, je šance, že se tohle nedorozumění napraví. Třetí bod plyne z předchozího – protože může docházet k nedorozuměním a redundance to může opravit, slouží k ujištění, že se chápeme správně.
Pokud to chcete přeložit do jazyka kódování v počítačovém světě, ty redundantní informace mají dvě role – jedna přenáší kontextové informace, které adresát nemusí mít; jednak fungují jako samoopravné kódy resp. jejich kontrolní součty – ujišťují vás, že přenos proběhl korektně, případně umí některé chyby přenosu napravit. -
RaviseStříbrný podporovatel
> Pokud to správně chápu, každá informace, která se dá odvodit z kontextu, je podle vás zbytečná.
Ne. Ale už nevidím důvod se tu dál snažit.
-
Filip JirsákStříbrný podporovatel
Takže jste vynechal nějaké informace, které jste považoval za zbytečné. Ale ukázalo se, že zbytečné nejsou. No a stejné je to i u zdrojového kódu. I tam je lepší, když jsou tam nějaké informace navíc, než když nějaká informace chybí.
-
RaviseStříbrný podporovatel
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".
-
Kod ma byt citatelny pre cloveka, prave popisne nazvy metod a class su dolezite. Ak musim studovat implementaciu aby som sa dozvedel co vlastne metoda robi tak je nieco zle. Mali sme kodera ktory variables pomenovaval ok, y, zz..., potom clovek musel v kode hladat co vlastne dana variable znamena resp obsahuje. Za mna radsej dlhsie nazvy a citatelny kod ako nazvy typu fncBtnOkW()
