Fórum Root.cz
Hlavní témata => Vývoj => Téma založeno: Sirdhemond 10. 06. 2020, 17:21:09
-
Zdravím, jaké výhody přináší abstrakce u OOP? Tedy abstrakce pomocí interfaců a abstraktních tříd? Jak bych to měl třeba vysvětlit u přijímacího pohovoru?
-
ze jsou promenne i metody pekne pospolu obalene jednim objektem/tridou, ktera ucelene reprezentuje nejakou entitu.
a ze pak lze vytvaret hierarchii potomku a usetrit si tak psani kodu.
-
Pokud budete mít například službu, která posílá notifikace, můžete mít v interface metodu send(), která notifikaci pošle. Při běhu programu si pak budete moci vybrat, zda chcete posílat notifikaci SMSkou neb mailem - podle toho program zvolí konkrétní implementaci posílání notifikací SMSkou nebo mailem. Kód volající send přitom může zůstat beze změny - vždy se zavolá metoda send daného interface. Navíc můžete nové implementace přidávat později a v programu samotném nemusíte nic měnit. Takto můžete přidávat moduly i k programu, ke kterému nemáte zdrojové kódy (hodí se pro systém pluginů).
Pseudokód - odeslání SMS zprávy za použití interface Notifier:
// zpráva k odeslání:
Message m = new Message("Ahoj");
// budeme odesílat Notifierem, nyní konkrétně SMS Notifierem:
Notifier n = new SmsNotifier();
// odešleme
n->send(m);
// uživatel přihlášený v programu si může sám volit zasílání zpráv SMS nebo mailem, volbu má uloženou v preferencích svého profilu
// získám aktuálního uživatele
User u = User.getById(...);
// zpráva k odeslání:
Message m = new Message();
// načtení Notifiera kterého si uživatel v preferencích svého profilu zvolil:
Notifier n = u.getPreferences().getNotifier()
// nevíme, jakého Notifiera si uživatel zvolil, přesto bude kód fungovat:
n->send(m);
Další příklady: Úložiště může využívat uložení do databáze, do souborů nebo do cloudu - kam se data ve skutečnosti uloží záleží na výběru konkrétní implementace.
-
a ze pak lze vytvaret hierarchii potomku a usetrit si tak psani kodu.
Code reuse dědičností se považuje za antipattern.
-
Je to jako každá jiná abstrakce, zjednodušuje návrh použitím vhodného modelu. Klíčové slovo je polymorfismus (rozhraní umožňuje typovat objekty dynamicky při zachování typové kontroly v době překladu).
-
a ze pak lze vytvaret hierarchii potomku a usetrit si tak psani kodu.
Code reuse dědičností se považuje za antipattern.
Rozhodně. Tohle bych zrovna doporučil neříkat. :-)
-
a ze pak lze vytvaret hierarchii potomku a usetrit si tak psani kodu.
Code reuse dědičností se považuje za antipattern.
a to jako proc?! pokud mam kod, ktery lze napsat uz v rodici a neni zavisly na specializaci potomka, tak patri do rodice.
-
a ze pak lze vytvaret hierarchii potomku a usetrit si tak psani kodu.
Code reuse dědičností se považuje za antipattern.
kdyz se spravne rozhodne zda se ma pouzit dedeni (IS it) nebo kompozice (HAS it), tak pak je dedicnost nebo naopak kompozice spravne. takze tvrdit, ze to je antipattern a smytec je antipattern.
ze muze dojit k vytvoreni "god object" jeste nesnizuje inheritanci a metody v rodici jako celek.
-
a ze pak lze vytvaret hierarchii potomku a usetrit si tak psani kodu.
Code reuse dědičností se považuje za antipattern.
a to jako proc?! pokud mam kod, ktery lze napsat uz v rodici a neni zavisly na specializaci potomka, tak patri do rodice.
Code reuse nesmí být jediným důvodem pro použití dědičnosti. Potomek musí být specializací předka.
-
a ze pak lze vytvaret hierarchii potomku a usetrit si tak psani kodu.
Code reuse dědičností se považuje za antipattern.
kdyz se spravne rozhodne zda se ma pouzit dedeni (IS it) nebo kompozice (HAS it), tak pak je dedicnost nebo naopak kompozice spravne. takze tvrdit, ze to je antipattern a smytec je antipattern.
Protože tohle ty neříkáš, že jo. Ty říkáš, že a ze pak lze vytvaret hierarchii potomku a usetrit si tak psani kodu.
Code reuse dědičností se považuje za antipattern.
a to jako proc?! pokud mam kod, ktery lze napsat uz v rodici a neni zavisly na specializaci potomka, tak patri do rodice.
Z čehož jsme pochopily, že se snažíš o reusable kódu pomocí dědičnosti. Což je antipattern a šmitec.
To, že nějaký kód patří do předka, protože tam patří, o tom už se dá bavit.
-
Z čehož jsme pochopily, že se snažíš o reusable kódu pomocí dědičnosti. Což je antipattern a šmitec.
proč, podle koho? Jaká to má negativa?
To, že nějaký kód patří do předka, protože tam patří, o tom už se dá bavit.
jak poznám, že tam patří?
-
Z čehož jsme pochopily, že se snažíš o reusable kódu pomocí dědičnosti. Což je antipattern a šmitec.
proč, podle koho? Jaká to má negativa?
Kromě ideového sporu, tak praxe mi ukazuje:
Heslovitě:
- prosakování implementace (předek rozumí potomkovi)
- neočekávané předpoklady (předek očekává, že potomek bude dělat něco, a ten netuší co)
- předek má podivné chování (protože to používá jeden potomek)
- voláme metodu, jejíž implementace je rozprsklá přes velké množství tříd
- neizolovatelný kód (voláme metodu, která vytváří objekt, který volá metodu, která vytváří objekt, a ten volá metodu - tu na začátku)
Jako obecně a subjektivně: když přijdu ke kódu, kde se používá dědičnost na reusable kódu, tak vím co mě čeká. Nepomáhá to, je to nepřehledné, nevím co se děje, nedá se to pořádně refaktorovat, testovat, nedá se s tím nic, než tiše trpět.
To, že nějaký kód patří do předka, protože tam patří, o tom už se dá bavit.
jak poznám, že tam patří?
Tak existuje klasické pravidlo, zda objekt IS nebo objekt HAS.
Případně jednodužší, pokud nemusíš, tak to nedělej.
Já jsem se naučil používat interface, abstraktním třídám a dědičnosti se spíše vyhýbám, a dost se mi to osvědčilo.
-
jak poznám, že tam patří?
Veřejnou dědičností se modelují vztahy is-a. O každém potomkovi by se mělo dát říct, že je zároveň předkem. Navíc to není podmínka postačující, ale jen nutná.
Takže do předka patří jen taková logika, kterou mají všichni potomci. Pokud dává smysl jen pro některé potomky, pak předek nejspíš není to pravé místo.
Příklad funkčnosti, která mi dává v předkovi smysl, je kontrola vstupů, návratových hodnot a invariantů.
Samozřejmě jako všechno u návrhu SW je to důsledné doporučení a nedá se tupě aplikovat vždycky a bez přemýšlení.
-
Zdravím, jaké výhody přináší abstrakce u OOP? Tedy abstrakce pomocí interfaců a abstraktních tříd? Jak bych to měl třeba vysvětlit u přijímacího pohovoru?
Možná by se dalo říct, že abstrakce umožňuje zobecnit problém s tím, že rozdělíme fázi pohled na celkový kontext a pohled na konkrétní implementaci/detaily. Čímž si jednak zjednodušíme život, protože nám to hlava pobere, a druhak umožníme, abychom mohli později vytvářet implementace, se kterými jsme na začátku ani nepočítali.
Interface s OOP imho nesouvisí. Ale Interface souvisí s tím, že dokážem vynutit, aby tam bylo nějaké rozhraní, které můžeme používat (pohled z celku), za kterým jsou schované detaily (pohled zevnitř).
Lépe než mnou to bylo vysvětleno v jednom rozhovoru na root.cz-u, ale nemohu ho najít.
-
jak poznám, že tam patří?
Veřejnou dědičností se modelují vztahy is-a. O každém potomkovi by se mělo dát říct, že je zároveň předkem. Navíc to není podmínka postačující, ale jen nutná.
Takže do předka patří jen taková logika, kterou mají všichni potomci. Pokud dává smysl jen pro některé potomky, pak předek nejspíš není to pravé místo.
Příklad funkčnosti, která mi dává v předkovi smysl, je kontrola vstupů, návratových hodnot a invariantů.
Samozřejmě jako všechno u návrhu SW je to důsledné doporučení a nedá se tupě aplikovat vždycky a bez přemýšlení.
V poslední době se v některých jazycích rozšířili traity/mixiny, které jsou určeny právě na to reusable kódu. Protože sice do objektu přidávají logiku, kterou chceme, ale nepřidávají, že potomek JE předek.
-
jak poznám, že tam patří?
Veřejnou dědičností se modelují vztahy is-a. O každém potomkovi by se mělo dát říct, že je zároveň předkem. Navíc to není podmínka postačující, ale jen nutná.
Takže do předka patří jen taková logika, kterou mají všichni potomci. Pokud dává smysl jen pro některé potomky, pak předek nejspíš není to pravé místo.
Příklad funkčnosti, která mi dává v předkovi smysl, je kontrola vstupů, návratových hodnot a invariantů.
Samozřejmě jako všechno u návrhu SW je to důsledné doporučení a nedá se tupě aplikovat vždycky a bez přemýšlení.
V poslední době se v některých jazycích rozšířili traity/mixiny, které jsou určeny právě na to reusable kódu. Protože sice do objektu přidávají logiku, kterou chceme, ale nepřidávají, že potomek JE předek.
Jop, tohle je dobrý příklad veřejné dědičnosti, která nemodeluje vztah JE. Typický je třeba Curously Recurring Template Pattern v C++ :
class Derived : public Base<Derived>
{
};
Předek není třída ale šablona, která potřebuje vědět typ potomka. Díky tomu se o vztahu JE vůbec nedá mluvit, protože ten předek sám o sobě není nějaká hotová věc.
Hodí se to třeba, pokud pro nějaká datová struktura potřebuje vestavěnou podporu ve vkládaných typech. Ta báze může třeba obsahovat ukazatele, aby se instance odvozené třídy daly strkat do spojového seznamu.
-
a vsecko tohle uz me na C++ pekne stve. kazdy primicha do kodu jinou metodologii a pak aby clovek umel vsecko.
proto zacinam pokukovat po Go, zas se neco zjednodusi a struktury s interface staci.
-
jak poznám, že tam patří?
Veřejnou dědičností se modelují vztahy is-a. O každém potomkovi by se mělo dát říct, že je zároveň předkem. Navíc to není podmínka postačující, ale jen nutná.
Takže do předka patří jen taková logika, kterou mají všichni potomci. Pokud dává smysl jen pro některé potomky, pak předek nejspíš není to pravé místo.
Příklad funkčnosti, která mi dává v předkovi smysl, je kontrola vstupů, návratových hodnot a invariantů.
Samozřejmě jako všechno u návrhu SW je to důsledné doporučení a nedá se tupě aplikovat vždycky a bez přemýšlení.
V poslední době se v některých jazycích rozšířili traity/mixiny, které jsou určeny právě na to reusable kódu. Protože sice do objektu přidávají logiku, kterou chceme, ale nepřidávají, že potomek JE předek.
Právě jsem je chtěl zmínit.
-
jak poznám, že tam patří?
Veřejnou dědičností se modelují vztahy is-a. O každém potomkovi by se mělo dát říct, že je zároveň předkem. Navíc to není podmínka postačující, ale jen nutná.
Takže do předka patří jen taková logika, kterou mají všichni potomci. Pokud dává smysl jen pro některé potomky, pak předek nejspíš není to pravé místo.
Příklad funkčnosti, která mi dává v předkovi smysl, je kontrola vstupů, návratových hodnot a invariantů.
Samozřejmě jako všechno u návrhu SW je to důsledné doporučení a nedá se tupě aplikovat vždycky a bez přemýšlení.
V poslední době se v některých jazycích rozšířili traity/mixiny, které jsou určeny právě na to reusable kódu. Protože sice do objektu přidávají logiku, kterou chceme, ale nepřidávají, že potomek JE předek.
Jop, tohle je dobrý příklad veřejné dědičnosti, která nemodeluje vztah JE. Typický je třeba Curously Recurring Template Pattern v C++ :
class Derived : public Base<Derived>
{
};
Předek není třída ale šablona, která potřebuje vědět typ potomka. Díky tomu se o vztahu JE vůbec nedá mluvit, protože ten předek sám o sobě není nějaká hotová věc.
Hodí se to třeba, pokud pro nějaká datová struktura potřebuje vestavěnou podporu ve vkládaných typech. Ta báze může třeba obsahovat ukazatele, aby se instance odvozené třídy daly strkat do spojového seznamu.
Tak C++ je vůbec divočina, tam je dědičnost tak mocná, že umožňuje psát higher kinded typy. Ne že by to tam bylo nějak zvlášť čitelné...
-
Tak C++ je vůbec divočina, tam je dědičnost tak mocná, že umožňuje psát higher kinded typy. Ne že by to tam bylo nějak zvlášť čitelné...
Jo, s čitelností je to horší. Šablony holt nebyly navržené pro tohle použití. Že jsou výpočetně úplné a co všechno se s nima dá udělat se zjistilo až dodatečně.
Naštěstí se spousta téhle divočiny dá udržet v implementaci knihoven. Samotné použití pak nevypadá až tak zle. A constexpr funkce a koncepty z C++20 tu čitelnost hodně zlepšují.
-
a vsecko tohle uz me na C++ pekne stve. kazdy primicha do kodu jinou metodologii a pak aby clovek umel vsecko.
proto zacinam pokukovat po Go, zas se neco zjednodusi a struktury s interface staci.
Proč ne raději Rust? Výkonově srovnatelný s C++, podobné koncepty (RAII apod.)?
-
a vsecko tohle uz me na C++ pekne stve. kazdy primicha do kodu jinou metodologii a pak aby clovek umel vsecko.
proto zacinam pokukovat po Go, zas se neco zjednodusi a struktury s interface staci.
Proč ne raději Rust? Výkonově srovnatelný s C++, podobné koncepty (RAII apod.)?
Třeba kvůli gorutinám a kanálům.
-
a vsecko tohle uz me na C++ pekne stve. kazdy primicha do kodu jinou metodologii a pak aby clovek umel vsecko.
proto zacinam pokukovat po Go, zas se neco zjednodusi a struktury s interface staci.
Proč ne raději Rust? Výkonově srovnatelný s C++, podobné koncepty (RAII apod.)?
Třeba kvůli gorutinám a kanálům.
Tebe jsem se neptal, sorry.
-
Obrovskou výhodou správně použité dědičnosti je vzájemná zaměnitelnost předka s potomky. Když mi jeden potomek nevyhovuje, tak místo něj použiji jiného. Zbytku aplikace se to nijak nedotkne, nemusím nic přepisovat. V případě programování proti interface je to ještě jednodušší a čitelnější, odpadá problém diamantu.
-
Dedeni vs interface je evergreen a porad to hromada lidi nechape.
Pritom zakladni hruby mechanismus je prosty.
Kdyz potrebuju rozsirit funkcionalitu pri zachovani stavajici - dedeni.
Kdyz potrebuju pracovat stejnym zpusobem s ruznymi objekty s ruznou vnitrni implementaci - interface.
Udelat bazovou tridu a v ni pulku metod overloadovat je kokotina.
A nejvetsi zadek je, ze se to normalne ve skolach uci, viz:
https://stackoverflow.com/questions/50793617/object-oriented-design-shapes
Je uplna hovadina dedit shapes (rectangle, triangle, circle), kdyz se pak dilci metody (obsah, bod je uvnitr apod) stejne pro kazdy typ pocita jinak.
To je typicky priklad na interface.
Typicky priklad na dedeni je treba plugin, tam mam par overloadovaych metod typu init(), execute(), destroy(), zbyle metody potrebne pro komunikaci s okolnim frameworkem zustavaji jak jsou a casto jsou este oznackovany "final", aby vubec overloadovat nesly.
-
Tak existuje klasické pravidlo, zda objekt IS nebo objekt HAS.
casto neni ani jedno, co treba mixiny? Je to dedeni, ale pouzivaji se treba pro pridavani atributu do trid.
pokusy o slovni popisy vyznamu kodu nefunguji.
-
Tak existuje klasické pravidlo, zda objekt IS nebo objekt HAS.
casto neni ani jedno, co treba mixiny? Je to dedeni, ale pouzivaji se treba pro pridavani atributu do trid.
pokusy o slovni popisy vyznamu kodu nefunguji.
Mixiny dělají akorát bordel v kódu. Snadno se píší, ale blbě se čtou. Přitom se dají jednoduše nahradit kompozicí.
-
Tak existuje klasické pravidlo, zda objekt IS nebo objekt HAS.
casto neni ani jedno, co treba mixiny? Je to dedeni, ale pouzivaji se treba pro pridavani atributu do trid.
pokusy o slovni popisy vyznamu kodu nefunguji.
Že mixin není ani IS ani HAS ještě neznamená, že slovní popisy nefungují. Mixin je něco, co přimixuju a co mohu poměrně svobodně přimixovávat právě bez ohledu na to, co objekt IS nebo HAS.
-
Tak existuje klasické pravidlo, zda objekt IS nebo objekt HAS.
casto neni ani jedno, co treba mixiny? Je to dedeni, ale pouzivaji se treba pro pridavani atributu do trid.
pokusy o slovni popisy vyznamu kodu nefunguji.
Mixiny dělají akorát bordel v kódu. Snadno se píší, ale blbě se čtou. Přitom se dají jednoduše nahradit kompozicí.
na mixinech jsou postavene nektere opravdu hodne uspesne knihovny. Me zajima, co se osvedcilo v praxi, ne co je "spatne" podle teoretiku v diskuzi. Jazykove konstrukty nemaji zadny filozoficky vyznam.
-
Tak existuje klasické pravidlo, zda objekt IS nebo objekt HAS.
casto neni ani jedno, co treba mixiny? Je to dedeni, ale pouzivaji se treba pro pridavani atributu do trid.
pokusy o slovni popisy vyznamu kodu nefunguji.
Že mixin není ani IS ani HAS ještě neznamená, že slovní popisy nefungují. Mixin je něco, co přimixuju a co mohu poměrně svobodně přimixovávat právě bez ohledu na to, co objekt IS nebo HAS.
Slovni popisy nefunguji, protoze programy nepiseme v prirozenem jazyce.
-
Tak existuje klasické pravidlo, zda objekt IS nebo objekt HAS.
casto neni ani jedno, co treba mixiny? Je to dedeni, ale pouzivaji se treba pro pridavani atributu do trid.
pokusy o slovni popisy vyznamu kodu nefunguji.
Že mixin není ani IS ani HAS ještě neznamená, že slovní popisy nefungují. Mixin je něco, co přimixuju a co mohu poměrně svobodně přimixovávat právě bez ohledu na to, co objekt IS nebo HAS.
Slovni popisy nefunguji, protoze programy nepiseme v prirozenem jazyce.
Komentáře jsou psané přirozeným jazykem. Sémantika toho programovacího jazyka bývá taky popsaná přirozeným jazykem.
Troufnu si tvrdit, že veškeré nedostatky formálních jazyků flíkujeme právě tím přirozeným. Což je pro mně dostatečný důkaz toho, že slovní popisy fungují.
-
Komentáře jsou psané přirozeným jazykem. Sémantika toho programovacího jazyka bývá taky popsaná přirozeným jazykem.
Troufnu si tvrdit, že veškeré nedostatky formálních jazyků flíkujeme právě tím přirozeným. Což je pro mně dostatečný důkaz toho, že slovní popisy fungují.
pouzivani slovnich komentaru je na ustupu, nahrazuji je doctesty, typove anotace.
-
Mixiny dělají akorát bordel v kódu. Snadno se píší, ale blbě se čtou. Přitom se dají jednoduše nahradit kompozicí.
Mixiny jsou druh kompozice. Akorát na rozdíl od kompozice přes membery nebo privátní dědičnost se skládá i vnější rozhraní třídy.
Spousta jazyků neumí jednoduše vytáhnout rozhraní membera do rozhraní třídy, takže alternativa k mixinům je psaní boilerplate kódu. Ten boilerplate kód se možná snáze čte, ale zase hůř modifikuje. Úpravy boilerplate kódu bývají náchylné k chybám, protože je to mechanická dělničina.
-
pouzivani slovnich komentaru je na ustupu, nahrazuji je doctesty, typove anotace.
Doctest je dokumentace s kousky zdrojáku. Místo komentářů se používají ve chvíli, kdy se soustředím na formátování toho přirozeného textu. Ve chvíli, kdy se neklade důraz na ten slovní popis, tak nemá cenu psát doctest.
Typové anotace přidávají statické typy do dynamicky typovaných jazyků. Pořád je třeba nějak specifikovat, co ty typy dělají.
BTW : Název něčeho je primárně slovní popis pro nás. Pro překladač je "v0a25" stejně dobrý název jako cokoliv jiného. Jen my lidi jsme bez tohohle slovního popisu těžce v pasti.
-
Komentáře jsou psané přirozeným jazykem. Sémantika toho programovacího jazyka bývá taky popsaná přirozeným jazykem.
Troufnu si tvrdit, že veškeré nedostatky formálních jazyků flíkujeme právě tím přirozeným. Což je pro mně dostatečný důkaz toho, že slovní popisy fungují.
pouzivani slovnich komentaru je na ustupu, nahrazuji je doctesty, typove anotace.
Slovní komentáře jsou prakticky nenahraditelné pro dovysvětlení záměru nebo kontextu. Nechápu, proč pořád chrlíš nějaké zjednodušující rezolutní závěry.
Naopak nevím, co myslel předřečník tím nedostatkem formálních jazyků.
-
Nechápu, proč pořád chrlíš nějaké zjednodušující rezolutní závěry.
zjednodusujici rezolutni zaver s HAS a IS tu psali ostastni
-
Slovní komentáře jsou prakticky nenahraditelné pro dovysvětlení záměru nebo kontextu.
V čem jsou slovní komentáře nenahraditelné? Od toho tu jsou přece názvy věcí, aby vysvětlily vše potřebné.
-
Slovní komentáře jsou prakticky nenahraditelné pro dovysvětlení záměru nebo kontextu.
V čem jsou slovní komentáře nenahraditelné? Od toho tu jsou přece názvy věcí, aby vysvětlily vše potřebné.
Ony vysvětlí, proč jsi použil bubble sort namísto quick sortu, viď. Nebo proč nějaký vstup od 3. strany ošetřuješ zrovna takhle, když posílá jiný formát odpovědi, než říká dokumentace.
-
Slovní komentáře jsou prakticky nenahraditelné pro dovysvětlení záměru nebo kontextu.
V čem jsou slovní komentáře nenahraditelné? Od toho tu jsou přece názvy věcí, aby vysvětlily vše potřebné.
Ony vysvětlí, proč jsi použil bubble sort namísto quick sortu, viď. Nebo proč nějaký vstup od 3. strany ošetřuješ zrovna takhle, když posílá jiný formát odpovědi, než říká dokumentace.
To patří spíš do dokumentace, ne?
-
Slovní komentáře jsou prakticky nenahraditelné pro dovysvětlení záměru nebo kontextu.
V čem jsou slovní komentáře nenahraditelné? Od toho tu jsou přece názvy věcí, aby vysvětlily vše potřebné.
Ony vysvětlí, proč jsi použil bubble sort namísto quick sortu, viď. Nebo proč nějaký vstup od 3. strany ošetřuješ zrovna takhle, když posílá jiný formát odpovědi, než říká dokumentace.
To patří spíš do dokumentace, ne?
Tím bych si nebyl až tak jistý. Dokumentace je ještě o krok dál od kódu, než komentáře. A i komentáře bývají dost často zastaralé. Dokumentuje se navíc hlavně API. Zdůvodnění implementačních detailů jsem v dokumentaci moc často nepotkal.
A kdy jste naposled při bisectování gitu bisectoval současně i dokumentaci? ;)
-
Tak existuje klasické pravidlo, zda objekt IS nebo objekt HAS.
casto neni ani jedno
Nevím, s tím jsem se v praxi nesetkal. Buď objekt je předek - dědím, nebo má vlastnost - komponuji, nebo nemá ani jedno, tak nedělám ani jedno.
co treba mixiny? Je to dedeni, ale pouzivaji se treba pro pridavani atributu do trid.
V kterém jazyce jsou mixiny dědění? Neříkám, že ne, ale co jsem se setkal traity (php), nebo mixiny (c#) nepřidávají do projektu vlastnost předka - což je taková asi z těch zásadnějších výhrad: já nechci, aby prase bylo kočka, já chci jen aby chodilo.
-
V kterém jazyce jsou mixiny dědění?
v jazycich s vicenasobnou dedicnosti se mixiny implementuji dedenim, treba v pythonu je to bezny pattern. Pouzivaji to hojne popularni knihovny. Treba https://docs.sqlalchemy.org/en/13/orm/extensions/declarative/mixins.html
-
V kterém jazyce jsou mixiny dědění?
v jazycich s vicenasobnou dedicnosti se mixiny implementuji dedenim, treba v pythonu je to bezny pattern. Pouzivaji to hojne popularni knihovny. Treba https://docs.sqlalchemy.org/en/13/orm/extensions/declarative/mixins.html
OK. Díky za příklad. Tak je to Python, tam to s těmi typy je takové... Každopádně pak tu zůstává ta otázka s tou přehledností.
-
V kterém jazyce jsou mixiny dědění?
v jazycich s vicenasobnou dedicnosti se mixiny implementuji dedenim, treba v pythonu je to bezny pattern. Pouzivaji to hojne popularni knihovny. Treba https://docs.sqlalchemy.org/en/13/orm/extensions/declarative/mixins.html
OK. Díky za příklad. Tak je to Python, tam to s těmi typy je takové... Každopádně pak tu zůstává ta otázka s tou přehledností.
je to normalni vicenasobna dedicnost, kompatibilni se statickym typovanim i s protokoly
https://mypy.readthedocs.io/en/latest/more_types.html#mixin-classes
-
V kterém jazyce jsou mixiny dědění?
v jazycich s vicenasobnou dedicnosti se mixiny implementuji dedenim, treba v pythonu je to bezny pattern. Pouzivaji to hojne popularni knihovny. Treba https://docs.sqlalchemy.org/en/13/orm/extensions/declarative/mixins.html
OK. Díky za příklad. Tak je to Python, tam to s těmi typy je takové... Každopádně pak tu zůstává ta otázka s tou přehledností.
Přehledné to moc není. Určitě bych se vícenásobné dědičnosti vyhnul.
-
Jak python pro větší projekty nemám rád, tak zrovna jeho mixiny jsou velice užitečné a v javě je kostrbatě emulujeme defaultními metodami interfaců.
-
Jak python pro větší projekty nemám rád, tak zrovna jeho mixiny jsou velice užitečné a v javě je kostrbatě emulujeme defaultními metodami interfaců.
V čem je to kostrbaté? Možná jen v tom, že se míchá něco, co se míchat nemá.
-
To je přece úplně jasné - defaultní metody jsou vždy public (novější java aspoň umožňuje kód vytáhnout do privátních metody, které ale z principu nejdou přetížit, kdyby bylo potřeba) a interface nemůže mít atributy, takže se musí v implementaci pro ně implementovat gettery a settery, což je ošklivé a otravné. Nicméně výhoda snadné kompozice takových funkčních bloků a možnost tyhle vzájemně nijak nepříbuzné "mixiny" předávat do metod pracujících s danými interfacy v řadě případů převáží nad opruzem s atributy.
-
Komentáře jsou psané přirozeným jazykem. Sémantika toho programovacího jazyka bývá taky popsaná přirozeným jazykem.
Troufnu si tvrdit, že veškeré nedostatky formálních jazyků flíkujeme právě tím přirozeným. Což je pro mně dostatečný důkaz toho, že slovní popisy fungují.
pouzivani slovnich komentaru je na ustupu, nahrazuji je doctesty, typove anotace.
Slovní komentáře jsou prakticky nenahraditelné pro dovysvětlení záměru nebo kontextu. Nechápu, proč pořád chrlíš nějaké zjednodušující rezolutní závěry.
Naopak nevím, co myslel předřečník tím nedostatkem formálních jazyků.
TL;DR: kód bez slovních komentářů je utopie. Jsme lidi a potřebujeme okomentovat spoustu "neformálních" (a realisticky neformalizovatelných) okolností.
Nedostatků formálních jazyků je habaděj. Např.: z definice jsou vymyšlené tak, aby měly přesnou sémantiku, čili (1) ta sémantika je nějak "ořezaná" (odstraní se nejednoznačnosti apod.) a tím jazyk získává přesnost na úkor expresivnosti. Typicky je taky formální jazyk (2) ušitý na míru nějaké doméně - opět ztrácí obecnou expresivnost. Prakticky vždycky je taky (3) formální jazyk konstruovaný tak, že některé koncepty, které v přirozeném jazyce vyjádřit umíme, v něm vyjádřit nejdou (záměrně - protože jejich vyjádření by jazyk neúměrně zkomplikovalo a buď by bylo složité s ním pracovat strojově, nebo by byl těžko srozumitelný pro lidi).
Pokud by nebyl programovací jazyk míň expresivní než přirozený, komentáře by nebyly potřeba, protože sám program by vyjadřoval všechno, včetně záměru autora, kontextu volby algoritmu apod. Tak to ale není, komentáře potřeba jsou, abych tam třeba dovysvětlil, že "toto řešení se mi zdá rozumnější, protože je sice míň efektivní, ale je líp čitelné a nejsme v kritické sekci programu" (případ (1)), "tohle je quick&dirty, protože zákazník je ve finanční tísni a potřebujeme to rychle dotáhnout, není čas na hrdinství" (2) nebo "tento kód je teď jenom placeholder pro kontroller, plnou implementaci dodělám, až bude čas" (případ (3) - vyjádření časově závislé individuové role je docela obtížně formalizovatelné).
-
Komentáře jsou psané přirozeným jazykem. Sémantika toho programovacího jazyka bývá taky popsaná přirozeným jazykem.
Troufnu si tvrdit, že veškeré nedostatky formálních jazyků flíkujeme právě tím přirozeným. Což je pro mně dostatečný důkaz toho, že slovní popisy fungují.
pouzivani slovnich komentaru je na ustupu, nahrazuji je doctesty, typove anotace.
Slovní komentáře jsou prakticky nenahraditelné pro dovysvětlení záměru nebo kontextu. Nechápu, proč pořád chrlíš nějaké zjednodušující rezolutní závěry.
Naopak nevím, co myslel předřečník tím nedostatkem formálních jazyků.
TL;DR: kód bez slovních komentářů je utopie. Jsme lidi a potřebujeme okomentovat spoustu "neformálních" (a realisticky neformalizovatelných) okolností.
Nedostatků formálních jazyků je habaděj. Např.: z definice jsou vymyšlené tak, aby měly přesnou sémantiku, čili (1) ta sémantika je nějak "ořezaná" (odstraní se nejednoznačnosti apod.) a tím jazyk získává přesnost na úkor expresivnosti. Typicky je taky formální jazyk (2) ušitý na míru nějaké doméně - opět ztrácí obecnou expresivnost. Prakticky vždycky je taky (3) formální jazyk konstruovaný tak, že některé koncepty, které v přirozeném jazyce vyjádřit umíme, v něm vyjádřit nejdou (záměrně - protože jejich vyjádření by jazyk neúměrně zkomplikovalo a buď by bylo složité s ním pracovat strojově, nebo by byl těžko srozumitelný pro lidi).
Pokud by nebyl programovací jazyk míň expresivní než přirozený, komentáře by nebyly potřeba, protože sám program by vyjadřoval všechno, včetně záměru autora, kontextu volby algoritmu apod. Tak to ale není, komentáře potřeba jsou, abych tam třeba dovysvětlil, že "toto řešení se mi zdá rozumnější, protože je sice míň efektivní, ale je líp čitelné a nejsme v kritické sekci programu" (případ (1)), "tohle je quick&dirty, protože zákazník je ve finanční tísni a potřebujeme to rychle dotáhnout, není čas na hrdinství" (2) nebo "tento kód je teď jenom placeholder pro kontroller, plnou implementaci dodělám, až bude čas" (případ (3) - vyjádření časově závislé individuové role je docela obtížně formalizovatelné).
Tohle je pokus o filosofování? ;)
-
Tohle je pokus o filosofování? ;)
Jako obvykle :)
-
Nedostatků formálních jazyků je habaděj. Např.: z definice jsou vymyšlené tak, aby měly přesnou sémantiku, čili (1) ta sémantika je nějak "ořezaná" (odstraní se nejednoznačnosti apod.) a tím jazyk získává přesnost na úkor expresivnosti. Typicky je taky formální jazyk (2) ušitý na míru nějaké doméně - opět ztrácí obecnou expresivnost. Prakticky vždycky je taky (3) formální jazyk konstruovaný tak, že některé koncepty, které v přirozeném jazyce vyjádřit umíme, v něm vyjádřit nejdou (záměrně - protože jejich vyjádření by jazyk neúměrně zkomplikovalo a buď by bylo složité s ním pracovat strojově, nebo by byl těžko srozumitelný pro lidi).
Pokud by nebyl programovací jazyk míň expresivní než přirozený, komentáře by nebyly potřeba, protože sám program by vyjadřoval všechno, včetně záměru autora, kontextu volby algoritmu apod. Tak to ale není, komentáře potřeba jsou, abych tam třeba dovysvětlil, že "toto řešení se mi zdá rozumnější, protože je sice míň efektivní, ale je líp čitelné a nejsme v kritické sekci programu" (případ (1)), "tohle je quick&dirty, protože zákazník je ve finanční tísni a potřebujeme to rychle dotáhnout, není čas na hrdinství" (2) nebo "tento kód je teď jenom placeholder pro kontroller, plnou implementaci dodělám, až bude čas" (případ (3) - vyjádření časově závislé individuové role je docela obtížně formalizovatelné).
Vidím to poněkud jinak. Program může obsahovat v zásadě čtyři skupiny informací:
CO se má stát. (Nutné, proto tu ten program je).
JAK se to má stát. (V ideálním světě si to překladač nějak odvodí z deklarace, ale v tom reálném se mu musí pomáhat).
PROČ se to má stát. (Zasazení kusu kódu do kontextu, aby se v tom programátor lépe orientoval).
A PROČ SE TO DĚLÁ ZROVNA TAKHLE. (Vysvětlení konkrétního rozhodnutí pro danou implementaci).
První dvě skupiny jsou "mezi počítačem a člověkem" a zde je myslím obecně přijímáno, že formální jazyk je ideální prostředek, protože je úsporný a jednoznačný. Zbylé dvě skupiny informací jsou jednak volitelné (program bez nich funguje dobře) a jednak slouží pouze pro referenci, když programátor potřebuje. V ostatních případech je to šum, který pouze odvádí pozornost a kdyby se i nakrásně povedlo formalizovat komentář, stroji by to nepomohlo (informace pro něj není určena) a lidem by to překáželo, protože TLDR, že ano.
Jinými slovy, programovací jazyk výborně slouží účelu, ke kterému je navržen a komentář slouží dobře ostatním účelům. To není známka nedokonalosti formálních jazyků. V obecném slova smyslu jistě platí, že formalizovaná komunikace mezi lidmi není efektivní, ale v rámci naší původní debaty to myslím nehraje roli.
-
Budu asi trochu slovíčkařit, ale jedna část je IMO silně zavádějící.
Vidím to poněkud jinak. Program může obsahovat v zásadě čtyři skupiny informací:
CO se má stát. (Nutné, proto tu ten program je).
JAK se to má stát. (V ideálním světě si to překladač nějak odvodí z deklarace, ale v tom reálném se mu musí pomáhat).
PROČ se to má stát. (Zasazení kusu kódu do kontextu, aby se v tom programátor lépe orientoval).
A PROČ SE TO DĚLÁ ZROVNA TAKHLE. (Vysvětlení konkrétního rozhodnutí pro danou implementaci).
První dvě skupiny jsou "mezi počítačem a člověkem" a zde je myslím obecně přijímáno, že formální jazyk je ideální prostředek, protože je úsporný a jednoznačný. Zbylé dvě skupiny informací jsou jednak volitelné (program bez nich funguje dobře) a jednak slouží pouze pro referenci, když programátor potřebuje. V ostatních případech je to šum, který pouze odvádí pozornost a kdyby se i nakrásně povedlo formalizovat komentář, stroji by to nepomohlo (informace pro něj není určena) a lidem by to překáželo, protože TLDR, že ano.
Jinými slovy, programovací jazyk výborně slouží účelu, ke kterému je navržen a komentář slouží dobře ostatním účelům. To není známka nedokonalosti formálních jazyků. V obecném slova smyslu jistě platí, že formalizovaná komunikace mezi lidmi není efektivní, ale v rámci naší původní debaty to myslím nehraje roli.
Ty druhé dvě skupiny nejsou až tak volitelné jako spíš naprosto kritické. Psát kód, kterému rozumí stroj, umí každý blbec. Proto se drtivá většina toho, co dělá profesionála profesionálem točí kolem té druhé půlky. Pojmenování, ustálené obraty, návrhové vzory, dokumentace, ... Všechno se to dělá proto, že software se primárně nepíše pro stroj ale pro lidi.
Program bez bodů 3 a 4 sice zatím funguje, ale je to časovaná bomba, která dříve či později bouchne. A až se tak stane tak za sebou nechává pochroumané trosky firem co na ten program spoléhaly a vyhořelé duše ubožáků, co ten binec museli udržovat a flíkovat.
-
Tohle je pokus o filosofování? ;)
Jako obvykle :)
Tak rozveď něco zajímavého, třeba literate programming ;)
-
Budu asi trochu slovíčkařit, ale jedna část je IMO silně zavádějící.
Program bez bodů 3 a 4 sice zatím funguje, ale je to časovaná bomba, která dříve či později bouchne. A až se tak stane tak za sebou nechává pochroumané trosky firem co na ten program spoléhaly a vyhořelé duše ubožáků, co ten binec museli udržovat a flíkovat.
Nejsme ve při. U nás v práci komentujeme hodně. A hodně se zlobím, když se někdo nesnaží vcítit do chudáka kolegy, který za pár let bude muset bádat, proč je někde něco nějak.
-
Budu asi trochu slovíčkařit, ale jedna část je IMO silně zavádějící.
Program bez bodů 3 a 4 sice zatím funguje, ale je to časovaná bomba, která dříve či později bouchne. A až se tak stane tak za sebou nechává pochroumané trosky firem co na ten program spoléhaly a vyhořelé duše ubožáků, co ten binec museli udržovat a flíkovat.
Nejsme ve při. U nás v práci komentujeme hodně. A hodně se zlobím, když se někdo nesnaží vcítit do chudáka kolegy, který za pár let bude muset bádat, proč je někde něco nějak.
Chrocht, ehm teda souhlas. :) Já se hlavně bál, že nějaký začátečník nepochopí, že ta volitelnost je tak na úrovni volby skoku pod vlak.
-
Tak rozveď něco zajímavého, třeba literate programming ;)
Co na tom chceš rozvádět? Jak už to tak bývá, zajímavej nápad, kterej se původně nepodařilo uspokojivě zrealizovat, aby se po pětadvaceti letech znovu vynořil v jiné podobě různých těch Jupyter Notebooků, interaktivních JS notebooků apod. a nikoho původní myšlenka nezajímá ;)
P.S. BTW, tak mě teď napadl jinej podobnej někdejší buzzword: sémantický web. Kde je mu konec a v jaké modifikované podobě se asi za dvacet let vynoří? :)
-
Tak rozveď něco zajímavého, třeba literate programming ;)
Co na tom chceš rozvádět? Jak už to tak bývá, zajímavej nápad, kterej se původně nepodařilo uspokojivě zrealizovat, aby se po pětadvaceti letech znovu vynořil v jiné podobě různých těch Jupyter Notebooků, interaktivních JS notebooků apod. a nikoho původní myšlenka nezajímá ;)
P.S. BTW, tak mě teď napadl jinej podobnej někdejší buzzword: sémantický web. Kde je mu konec a v jaké modifikované podobě se asi za dvacet let vynoří? :)
Já nikdy nepochopil, co má sémantický web být. U většiny buzzwordů aspoň chápu myšlenku za konceptem.
-
Budu asi trochu slovíčkařit, ale jedna část je IMO silně zavádějící.
Program bez bodů 3 a 4 sice zatím funguje, ale je to časovaná bomba, která dříve či později bouchne. A až se tak stane tak za sebou nechává pochroumané trosky firem co na ten program spoléhaly a vyhořelé duše ubožáků, co ten binec museli udržovat a flíkovat.
Nejsme ve při. U nás v práci komentujeme hodně. A hodně se zlobím, když se někdo nesnaží vcítit do chudáka kolegy, který za pár let bude muset bádat, proč je někde něco nějak.
Komentar v kodu beru jako svoje selhani pri snaze napsat sebevysvetlujici kod. Snazim se jich mit co nejmin a ostatni k tomu nabadam taky.
Osvedcilo se mi to.
-
Komentar v kodu beru jako svoje selhani pri snaze napsat sebevysvetlujici kod. Snazim se jich mit co nejmin a ostatni k tomu nabadam taky.
Osvedcilo se mi to.
No tak si to užij. Akorát si dovolím podotknout, že tady nikdo netvrdil, že kód má být nepřehledný a že komentář je od toho, aby to kompenzoval.
-
Co na tom chceš rozvádět? Jak už to tak bývá, zajímavej nápad, kterej se původně nepodařilo uspokojivě zrealizovat, aby se po pětadvaceti letech znovu vynořil v jiné podobě různých těch Jupyter Notebooků, interaktivních JS notebooků apod. a nikoho původní myšlenka nezajímá
Jupyter je kopie Wolfram Mathematica, existuje už 30 let
-
Komentar v kodu beru jako svoje selhani pri snaze napsat sebevysvetlujici kod. Snazim se jich mit co nejmin a ostatni k tomu nabadam taky.
Osvedcilo se mi to.
No tak si to užij. Akorát si dovolím podotknout, že tady nikdo netvrdil, že kód má být nepřehledný a že komentář je od toho, aby to kompenzoval.
Taky sem nerekl, ze to nekdo tvrdil. byla to reakce na to ze "komentujeme hodne". To mi rika, ze je neco spatne....
EDIT: Muzes sem treba dat kus kodu, ktery podle tebe vyzaduje byti hodne okomentovan. Rad bych ho videl.
-
Komentar v kodu beru jako svoje selhani pri snaze napsat sebevysvetlujici kod. Snazim se jich mit co nejmin a ostatni k tomu nabadam taky.
Osvedcilo se mi to.
No tak si to užij. Akorát si dovolím podotknout, že tady nikdo netvrdil, že kód má být nepřehledný a že komentář je od toho, aby to kompenzoval.
Taky sem nerekl, ze to nekdo tvrdil. byla to reakce na to ze "komentujeme hodne". To mi rika, ze je neco spatne....
EDIT: Muzes sem treba dat kus kodu, ktery podle tebe vyzaduje byti hodne okomentovan. Rad bych ho videl.
Nemůžu, ani kdybych chtěl. Je pravda, že se u nás nacházejí oblasti kódu, kde některé komentáře jsou nadbytečné a je to jistě i věc názoru. Máš Ty nějaký vzorový kód, kde je komentářů "akorát"? Nemusí být vlastní, klidně nějaký profláknutý open source.
-
Komentar v kodu beru jako svoje selhani pri snaze napsat sebevysvetlujici kod. Snazim se jich mit co nejmin a ostatni k tomu nabadam taky.
Osvedcilo se mi to.
No tak si to užij. Akorát si dovolím podotknout, že tady nikdo netvrdil, že kód má být nepřehledný a že komentář je od toho, aby to kompenzoval.
Taky sem nerekl, ze to nekdo tvrdil. byla to reakce na to ze "komentujeme hodne". To mi rika, ze je neco spatne....
EDIT: Muzes sem treba dat kus kodu, ktery podle tebe vyzaduje byti hodne okomentovan. Rad bych ho videl.
Nevím co Ink, ale já místo "Komentar v kodu beru jako svoje selhani..." volím "Když si nejsem jistý, tak raději komentuju". Protože jestli jsem při psaní toho sebevysvětlujícího kódu selhal nebo ne se pozná až někdy v budoucnosti.
A i nejlepší sebevysvětlující kód neříká nic o důvodech. Proč původní autor udělal tohle a ne tamto? Měl k tomu nějaký důvod, nebo ho to jenom nenapadlo?
-
Komentar v kodu beru jako svoje selhani pri snaze napsat sebevysvetlujici kod. Snazim se jich mit co nejmin a ostatni k tomu nabadam taky.
Osvedcilo se mi to.
Věřím, že se to může osvědčit, pokud se tím autor stane pro zaměstnavatele nepostradatelným, protože nikdo jiný jeho kód nedokáže dál udržovat.
-
Komentar v kodu beru jako svoje selhani pri snaze napsat sebevysvetlujici kod. Snazim se jich mit co nejmin a ostatni k tomu nabadam taky.
Osvedcilo se mi to.
Věřím, že se to může osvědčit, pokud se tím autor stane pro zaměstnavatele nepostradatelným, protože nikdo jiný jeho kód nedokáže dál udržovat.
To ale nemuze byt muj pripad a stejne se mi to osvedcilo...
-
Věřím, že se to může osvědčit, pokud se tím autor stane pro zaměstnavatele nepostradatelným, protože nikdo jiný jeho kód nedokáže dál udržovat.
To ale nemuze byt muj pripad ...
Pravidelně na dlažbě? ;)
-
Tak rozveď něco zajímavého, třeba literate programming ;)
Co na tom chceš rozvádět? Jak už to tak bývá, zajímavej nápad, kterej se původně nepodařilo uspokojivě zrealizovat, aby se po pětadvaceti letech znovu vynořil v jiné podobě různých těch Jupyter Notebooků, interaktivních JS notebooků apod. a nikoho původní myšlenka nezajímá ;)
P.S. BTW, tak mě teď napadl jinej podobnej někdejší buzzword: sémantický web. Kde je mu konec a v jaké modifikované podobě se asi za dvacet let vynoří? :)
Já nikdy nepochopil, co má sémantický web být. U většiny buzzwordů aspoň chápu myšlenku za konceptem.
Sémantický web měl být web, kde značky měly nést sémantický význam. Takže třeba v online obchodu bys měl značky jako cena, hmotnost, příkon, výkon, motor atd.
-
Komentar v kodu beru jako svoje selhani pri snaze napsat sebevysvetlujici kod. Snazim se jich mit co nejmin a ostatni k tomu nabadam taky.
Osvedcilo se mi to.
No tak si to užij. Akorát si dovolím podotknout, že tady nikdo netvrdil, že kód má být nepřehledný a že komentář je od toho, aby to kompenzoval.
Taky sem nerekl, ze to nekdo tvrdil. byla to reakce na to ze "komentujeme hodne". To mi rika, ze je neco spatne....
EDIT: Muzes sem treba dat kus kodu, ktery podle tebe vyzaduje byti hodne okomentovan. Rad bych ho videl.
Nemůžu, ani kdybych chtěl. Je pravda, že se u nás nacházejí oblasti kódu, kde některé komentáře jsou nadbytečné a je to jistě i věc názoru. Máš Ty nějaký vzorový kód, kde je komentářů "akorát"? Nemusí být vlastní, klidně nějaký profláknutý open source.
Tak co treba https://github.com/unclebob/fitnesse (https://github.com/unclebob/fitnesse). Porad mi tam prijdou nektery navic... ale jde to.
-
Věřím, že se to může osvědčit, pokud se tím autor stane pro zaměstnavatele nepostradatelným, protože nikdo jiný jeho kód nedokáže dál udržovat.
To ale nemuze byt muj pripad ...
Pravidelně na dlažbě? ;)
To ne, ale muj zamestavatel neni mym zakaznikem. Zamestnavatele mam staleho a zakazniky stridam tak cca kazde dva roky.
Navic jak rikam... tlacim na to aby to tak delali i ostatni v mem tymu.
-
Komentar v kodu beru jako svoje selhani pri snaze napsat sebevysvetlujici kod. Snazim se jich mit co nejmin a ostatni k tomu nabadam taky.
Osvedcilo se mi to.
No tak si to užij. Akorát si dovolím podotknout, že tady nikdo netvrdil, že kód má být nepřehledný a že komentář je od toho, aby to kompenzoval.
Taky sem nerekl, ze to nekdo tvrdil. byla to reakce na to ze "komentujeme hodne". To mi rika, ze je neco spatne....
EDIT: Muzes sem treba dat kus kodu, ktery podle tebe vyzaduje byti hodne okomentovan. Rad bych ho videl.
Nemůžu, ani kdybych chtěl. Je pravda, že se u nás nacházejí oblasti kódu, kde některé komentáře jsou nadbytečné a je to jistě i věc názoru. Máš Ty nějaký vzorový kód, kde je komentářů "akorát"? Nemusí být vlastní, klidně nějaký profláknutý open source.
Tak co treba https://github.com/unclebob/fitnesse (https://github.com/unclebob/fitnesse). Porad mi tam prijdou nektery navic... ale jde to.
Tak nevím, jestli jsem neměl smůlu. Otevřel jsem náhodně asi 10 souborů a ve všech byl jen boilerplate kód, který cosi předával tam a zpět. Nějakou aplikační logiku jsem nenašel. A z nějakého důvodu se mi vybavil FizzBuzz Enterprise.
-
Komentar v kodu beru jako svoje selhani pri snaze napsat sebevysvetlujici kod. Snazim se jich mit co nejmin a ostatni k tomu nabadam taky.
Osvedcilo se mi to.
No tak si to užij. Akorát si dovolím podotknout, že tady nikdo netvrdil, že kód má být nepřehledný a že komentář je od toho, aby to kompenzoval.
Taky sem nerekl, ze to nekdo tvrdil. byla to reakce na to ze "komentujeme hodne". To mi rika, ze je neco spatne....
EDIT: Muzes sem treba dat kus kodu, ktery podle tebe vyzaduje byti hodne okomentovan. Rad bych ho videl.
Nemůžu, ani kdybych chtěl. Je pravda, že se u nás nacházejí oblasti kódu, kde některé komentáře jsou nadbytečné a je to jistě i věc názoru. Máš Ty nějaký vzorový kód, kde je komentářů "akorát"? Nemusí být vlastní, klidně nějaký profláknutý open source.
Tak co treba https://github.com/unclebob/fitnesse (https://github.com/unclebob/fitnesse). Porad mi tam prijdou nektery navic... ale jde to.
Tak nevím, jestli jsem neměl smůlu. Otevřel jsem náhodně asi 10 souborů a ve všech byl jen boilerplate kód, který cosi předával tam a zpět. Nějakou aplikační logiku jsem nenašel. A z nějakého důvodu se mi vybavil FizzBuzz Enterprise.
Dej nejaky priklad... nevim o cem mluvis.
-
Komentar v kodu beru jako svoje selhani pri snaze napsat sebevysvetlujici kod. Snazim se jich mit co nejmin a ostatni k tomu nabadam taky.
Osvedcilo se mi to.
No tak si to užij. Akorát si dovolím podotknout, že tady nikdo netvrdil, že kód má být nepřehledný a že komentář je od toho, aby to kompenzoval.
Taky sem nerekl, ze to nekdo tvrdil. byla to reakce na to ze "komentujeme hodne". To mi rika, ze je neco spatne....
EDIT: Muzes sem treba dat kus kodu, ktery podle tebe vyzaduje byti hodne okomentovan. Rad bych ho videl.
Nemůžu, ani kdybych chtěl. Je pravda, že se u nás nacházejí oblasti kódu, kde některé komentáře jsou nadbytečné a je to jistě i věc názoru. Máš Ty nějaký vzorový kód, kde je komentářů "akorát"? Nemusí být vlastní, klidně nějaký profláknutý open source.
Tak co treba https://github.com/unclebob/fitnesse (https://github.com/unclebob/fitnesse). Porad mi tam prijdou nektery navic... ale jde to.
Tak nevím, jestli jsem neměl smůlu. Otevřel jsem náhodně asi 10 souborů a ve všech byl jen boilerplate kód, který cosi předával tam a zpět. Nějakou aplikační logiku jsem nenašel. A z nějakého důvodu se mi vybavil FizzBuzz Enterprise.
Dej nejaky priklad... nevim o cem mluvis.
Tak náhodně :
https://github.com/unclebob/fitnesse/blob/master/src/fitnesse/testrunner/CompositeFormatter.java (https://github.com/unclebob/fitnesse/blob/master/src/fitnesse/testrunner/CompositeFormatter.java) Nějaký listener, který distribuuje ty události dál. Akorát jsem tam nenašel nic, co by vypadalo jako formátování.
https://github.com/unclebob/fitnesse/blob/master/src/fitnesse/testrunner/ClassPathBuilder.java (https://github.com/unclebob/fitnesse/blob/master/src/fitnesse/testrunner/ClassPathBuilder.java) Podle názvu sestavuje nejaké cesty k nějakým třídám. Jaké cesty k jakým třídám? Takhle by to mohl být skoro SomethingDoer a vyšlo by to na stejno.
Mohl bych pokračovat dál a dál. Snažil jsem se být férový a najít nějakou výjimku, ale nenašel jsem nic. Nenašel jsem jedinou třídu, o které bych byl schopný vlastními slovy říct, co vlastně dělá. Jedná každá třída v tom projektu postrádá stručný komentář, který by říkal k čemu slouží. A z kódu jsem to nepoznal.
Představa, že bych měl tenhle kód udržovat, mě upřímně děsí.
-
Tak náhodně :
https://github.com/unclebob/fitnesse/blob/master/src/fitnesse/testrunner/CompositeFormatter.java (https://github.com/unclebob/fitnesse/blob/master/src/fitnesse/testrunner/CompositeFormatter.java) Nějaký listener, který distribuuje ty události dál. Akorát jsem tam nenašel nic, co by vypadalo jako formátování.
https://github.com/unclebob/fitnesse/blob/master/src/fitnesse/testrunner/ClassPathBuilder.java (https://github.com/unclebob/fitnesse/blob/master/src/fitnesse/testrunner/ClassPathBuilder.java) Podle názvu sestavuje nejaké cesty k nějakým třídám. Jaké cesty k jakým třídám? Takhle by to mohl být skoro SomethingDoer a vyšlo by to na stejno.
Mohl bych pokračovat dál a dál. Snažil jsem se být férový a najít nějakou výjimku, ale nenašel jsem nic. Nenašel jsem jedinou třídu, o které bych byl schopný vlastními slovy říct, co vlastně dělá. Jedná každá třída v tom projektu postrádá stručný komentář, který by říkal k čemu slouží. A z kódu jsem to nepoznal.
Představa, že bych měl tenhle kód udržovat, mě upřímně děsí.
Jsem rád, že nejsem sám, kdo se v tom ztratil. Podotýkám, že nejsem javista a nevěnoval jsem tomu moc času, ale tohle mít ve firemním repozitáři, asi bych se dost vyděsil. Komentáře jsem nenašel prakticky žádné, když nepočítám 6 řádků copyright v každém souboru. A když ano, bylo to něco jako:
// REFACTOR The fixture path is really the only part of this
-
Tak náhodně :
https://github.com/unclebob/fitnesse/blob/master/src/fitnesse/testrunner/CompositeFormatter.java (https://github.com/unclebob/fitnesse/blob/master/src/fitnesse/testrunner/CompositeFormatter.java) Nějaký listener, který distribuuje ty události dál. Akorát jsem tam nenašel nic, co by vypadalo jako formátování.
https://github.com/unclebob/fitnesse/blob/master/src/fitnesse/testrunner/ClassPathBuilder.java (https://github.com/unclebob/fitnesse/blob/master/src/fitnesse/testrunner/ClassPathBuilder.java) Podle názvu sestavuje nejaké cesty k nějakým třídám. Jaké cesty k jakým třídám? Takhle by to mohl být skoro SomethingDoer a vyšlo by to na stejno.
Mohl bych pokračovat dál a dál. Snažil jsem se být férový a najít nějakou výjimku, ale nenašel jsem nic. Nenašel jsem jedinou třídu, o které bych byl schopný vlastními slovy říct, co vlastně dělá. Jedná každá třída v tom projektu postrádá stručný komentář, který by říkal k čemu slouží. A z kódu jsem to nepoznal.
Představa, že bych měl tenhle kód udržovat, mě upřímně děsí.
Jsem rád, že nejsem sám, kdo se v tom ztratil. Podotýkám, že nejsem javista a nevěnoval jsem tomu moc času, ale tohle mít ve firemním repozitáři, asi bych se dost vyděsil. Komentáře jsem nenašel prakticky žádné, když nepočítám 6 řádků copyright v každém souboru. A když ano, bylo to něco jako:
// REFACTOR The fixture path is really the only part of this
Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
-
Jsem rád, že nejsem sám, kdo se v tom ztratil. Podotýkám, že nejsem javista a nevěnoval jsem tomu moc času, ale tohle mít ve firemním repozitáři, asi bych se dost vyděsil. Komentáře jsem nenašel prakticky žádné, když nepočítám 6 řádků copyright v každém souboru. A když ano, bylo to něco jako:
// REFACTOR The fixture path is really the only part of this
Taky nejsem Javista a taky jsem tomu nevěnoval až tak moc času. Na druhou stranu jsem nenarazil na jedinou konstrukci, které bych nerozuměl. Jednomu každému řádku rozumím, ale nějak nejsem schopný popsat, co se tam děje, na trochu vyšší úrovni. Težce mi tam chybí jakýkoliv kontext.
To ne, ale muj zamestavatel neni mym zakaznikem. Zamestnavatele mam staleho a zakazniky stridam tak cca kazde dva roky.
Navic jak rikam... tlacim na to aby to tak delali i ostatni v mem tymu.
Teď je otázka, jak se na váš samovysvětlující kód dívají ti, co ho po těch dvou letech mají převzít a dál udržovat.
-
To ne, ale muj zamestavatel neni mym zakaznikem. Zamestnavatele mam staleho a zakazniky stridam tak cca kazde dva roky.
Navic jak rikam... tlacim na to aby to tak delali i ostatni v mem tymu.
Teď je otázka, jak se na váš samovysvětlující kód dívají ti, co ho po těch dvou letech mají převzít a dál udržovat.
Vetsinou zustavam v kontaktu(kdyz to neni predavka do Indie a i tam obcas jo). A jeste mi nikdo nenadaval :-)
-
Jsem rád, že nejsem sám, kdo se v tom ztratil. Podotýkám, že nejsem javista a nevěnoval jsem tomu moc času, ale tohle mít ve firemním repozitáři, asi bych se dost vyděsil. Komentáře jsem nenašel prakticky žádné, když nepočítám 6 řádků copyright v každém souboru. A když ano, bylo to něco jako:
// REFACTOR The fixture path is really the only part of this
Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
Tak tohle mi třeba došlo poměrně rychle. ;)
Problém je, že mi tam dost chybí ostatní druhy komentářů. Že něco programátor neudělal mi moc nepomůže, když nevím co se vůbec snažil udělat.
-
Jsem rád, že nejsem sám, kdo se v tom ztratil. Podotýkám, že nejsem javista a nevěnoval jsem tomu moc času, ale tohle mít ve firemním repozitáři, asi bych se dost vyděsil. Komentáře jsem nenašel prakticky žádné, když nepočítám 6 řádků copyright v každém souboru. A když ano, bylo to něco jako:
// REFACTOR The fixture path is really the only part of this
Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
Tak tohle mi třeba došlo poměrně rychle. ;)
Problém je, že mi tam dost chybí ostatní druhy komentářů. Že něco programátor neudělal mi moc nepomůže, když nevím co se vůbec snažil udělat.
Me to prijde celkem evidentni... Mozna je tezky skocit do projektu o kterym nic nevim a vyznat se v nem...
Ale kdyz vim, ze je to bude poustet nejaky testy a ze mozna budu chtit nejaky vystupy tak uz to zacne davat smysl.
-
Jsem rád, že nejsem sám, kdo se v tom ztratil. Podotýkám, že nejsem javista a nevěnoval jsem tomu moc času, ale tohle mít ve firemním repozitáři, asi bych se dost vyděsil. Komentáře jsem nenašel prakticky žádné, když nepočítám 6 řádků copyright v každém souboru. A když ano, bylo to něco jako:
// REFACTOR The fixture path is really the only part of this
Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
Tak tohle mi třeba došlo poměrně rychle. ;)
Problém je, že mi tam dost chybí ostatní druhy komentářů. Že něco programátor neudělal mi moc nepomůže, když nevím co se vůbec snažil udělat.
Me to prijde celkem evidentni... Mozna je tezky skocit do projektu o kterym nic nevim a vyznat se v nem...
Ale kdyz vim, ze je to bude poustet nejaky testy a ze mozna budu chtit nejaky vystupy tak uz to zacne davat smysl.
Jak možná? Je zatraceně těžký skočit do projektu o kterým nic nevím a vyznat se v něm. A když je každá třída jako dílek puzzle, o kterém nevím jak zapadá do zbytku, tak je to ještě výrazně obtížnější.
Že to pouští nějaké testy a generuje nějaké výstupy je jasné. Akorát jsem při tom letmém procházení toho projektu nenarazil na nic, co by vypadalo jako pouštění nějakých testů nebo generování nějakých výstupů. A u jednotlivých tříd jsem nebyl schopný odhadnout, jakou část toho pouštění testů nebo generování výstupů mají vůbec na starost. Asi je to namleté moc najemno. Proto jsem taky zmiňoval ten boilerplate kód.
-
Jak možná? Je zatraceně těžký skočit do projektu o kterým nic nevím a vyznat se v něm. A když je každá třída jako dílek puzzle, o kterém nevím jak zapadá do zbytku, tak je to ještě výrazně obtížnější.
Že to pouští nějaké testy a generuje nějaké výstupy je jasné. Akorát jsem při tom letmém procházení toho projektu nenarazil na nic, co by vypadalo jako pouštění nějakých testů nebo generování nějakých výstupů. A u jednotlivých tříd jsem nebyl schopný odhadnout, jakou část toho pouštění testů nebo generování výstupů mají vůbec na starost. Asi je to namleté moc najemno. Proto jsem taky zmiňoval ten boilerplate kód.
Jasny... jako cist knizku od prostredka. Ale zajimalo by me jakej komentar by tam mel bejt aby mi to pomohlo tu skladacku slozit....
Jestli proste nebude lepsi cist tu knizku od zacatku.
-
Otevrel sem si spring-boot a nahodne klikal az najdu nejakou tridu a jestli tam bude komentar a co se z nej dozvim:
/**
* {@link HealthEndpointGroup} used to support availability probes.
*
* @author Phillip Webb
* @author Brian Clozel
*/
class AvailabilityProbesHealthEndpointGroup implements HealthEndpointGroup
Podle me vim stejny nic jako kdyby tam ten komentar nebyl.
-
Jak možná? Je zatraceně těžký skočit do projektu o kterým nic nevím a vyznat se v něm. A když je každá třída jako dílek puzzle, o kterém nevím jak zapadá do zbytku, tak je to ještě výrazně obtížnější.
Že to pouští nějaké testy a generuje nějaké výstupy je jasné. Akorát jsem při tom letmém procházení toho projektu nenarazil na nic, co by vypadalo jako pouštění nějakých testů nebo generování nějakých výstupů. A u jednotlivých tříd jsem nebyl schopný odhadnout, jakou část toho pouštění testů nebo generování výstupů mají vůbec na starost. Asi je to namleté moc najemno. Proto jsem taky zmiňoval ten boilerplate kód.
Jasny... jako cist knizku od prostredka. Ale zajimalo by me jakej komentar by tam mel bejt aby mi to pomohlo tu skladacku slozit....
Jestli proste nebude lepsi cist tu knizku od zacatku.
Minimálně by tam měly být nějaké základní informace ke každé třídě. Perlička z kódu:
// class that needs to be globally accessible.
public class FixtureLoader {
O třídě mi to řekne kulový, akorát deklaruje to zjevnou věc, tedy že třída je (OK, musí být) k dispozici globálně. Jasně, mám to pochopit z názvu, takže máme třeba třídu Parse, která NĚCO parsuje, neříká co, jak ani proč. A když je tam komentář v metodách (tohle NEJSOU až tak triviální věci), tak v jednom případě ze tří proto, aby zakomentoval řádek kódu. A pak je tam ještě komentář k metodě, cituji:
/* Added by Rick Mugridge, Feb 2005 */
Když to nepochopím, zeptám se Ricka, jak to před 15 lety myslel.
Hele, fakt nechci rýpat, ale tohle mi nepřijde jako dobrý vzorový případ.
-
Jak možná? Je zatraceně těžký skočit do projektu o kterým nic nevím a vyznat se v něm. A když je každá třída jako dílek puzzle, o kterém nevím jak zapadá do zbytku, tak je to ještě výrazně obtížnější.
Že to pouští nějaké testy a generuje nějaké výstupy je jasné. Akorát jsem při tom letmém procházení toho projektu nenarazil na nic, co by vypadalo jako pouštění nějakých testů nebo generování nějakých výstupů. A u jednotlivých tříd jsem nebyl schopný odhadnout, jakou část toho pouštění testů nebo generování výstupů mají vůbec na starost. Asi je to namleté moc najemno. Proto jsem taky zmiňoval ten boilerplate kód.
Jasny... jako cist knizku od prostredka. Ale zajimalo by me jakej komentar by tam mel bejt aby mi to pomohlo tu skladacku slozit....
Jestli proste nebude lepsi cist tu knizku od zacatku.
Minimálně by tam měly být nějaké základní informace ke každé třídě. Perlička z kódu:
// class that needs to be globally accessible.
public class FixtureLoader {
O třídě mi to řekne kulový, akorát deklaruje to zjevnou věc, tedy že třída je (OK, musí být) k dispozici globálně. Jasně, mám to pochopit z názvu, takže máme třeba třídu Parse, která NĚCO parsuje, neříká co, jak ani proč. A když je tam komentář v metodách (tohle NEJSOU až tak triviální věci), tak v jednom případě ze tří proto, aby zakomentoval řádek kódu. A pak je tam ještě komentář k metodě, cituji:
/* Added by Rick Mugridge, Feb 2005 */
Když to nepochopím, zeptám se Ricka, jak to před 15 lety myslel.
Hele, fakt nechci rýpat, ale tohle mi nepřijde jako dobrý vzorový případ.
Fajn... dej lepsi.
-
Jak možná? Je zatraceně těžký skočit do projektu o kterým nic nevím a vyznat se v něm. A když je každá třída jako dílek puzzle, o kterém nevím jak zapadá do zbytku, tak je to ještě výrazně obtížnější.
Že to pouští nějaké testy a generuje nějaké výstupy je jasné. Akorát jsem při tom letmém procházení toho projektu nenarazil na nic, co by vypadalo jako pouštění nějakých testů nebo generování nějakých výstupů. A u jednotlivých tříd jsem nebyl schopný odhadnout, jakou část toho pouštění testů nebo generování výstupů mají vůbec na starost. Asi je to namleté moc najemno. Proto jsem taky zmiňoval ten boilerplate kód.
Jasny... jako cist knizku od prostredka. Ale zajimalo by me jakej komentar by tam mel bejt aby mi to pomohlo tu skladacku slozit....
Jestli proste nebude lepsi cist tu knizku od zacatku.
Minimálně by tam měly být nějaké základní informace ke každé třídě. Perlička z kódu:
// class that needs to be globally accessible.
public class FixtureLoader {
O třídě mi to řekne kulový, akorát deklaruje to zjevnou věc, tedy že třída je (OK, musí být) k dispozici globálně. Jasně, mám to pochopit z názvu, takže máme třeba třídu Parse, která NĚCO parsuje, neříká co, jak ani proč. A když je tam komentář v metodách (tohle NEJSOU až tak triviální věci), tak v jednom případě ze tří proto, aby zakomentoval řádek kódu. A pak je tam ještě komentář k metodě, cituji:
/* Added by Rick Mugridge, Feb 2005 */
Když to nepochopím, zeptám se Ricka, jak to před 15 lety myslel.
Hele, fakt nechci rýpat, ale tohle mi nepřijde jako dobrý vzorový případ.
BTW. rikal sem, ze tam jsou komentare navic... ktery bych dal pryc.
A nikdy sem netvrdil, ze ty co tam jsou tak jsou k necemu dobry...
Takze me nezajima to co tam "je", ale to co ti tam chybi....
Zajimaly by me ty "zakladni informace".
Nejakej dobre priklad kde to je a kde je to fakt uzitecny...
Co sem si vsimnul tak vetsina barevnych schemat do IDE a editoru se snazi nejak potlacit komentare aby nebyli tolik videt.
Rikam si... procpak asi?
-
Co sem si vsimnul tak vetsina barevnych schemat do IDE a editoru se snazi nejak potlacit komentare aby nebyli tolik videt.
Rikam si... procpak asi?
Nejen v IDE, komentáře mám potlačeny i ve Vimu. Nevzpomínám si, že by mi byly někdy k užitku. Pohled do kódu mi řekne mnohem víc, rychleji a na rozdíl od komentářů vidím přesně, co ten kód dělá a nedělá.
-
Hele, fakt nechci rýpat, ale tohle mi nepřijde jako dobrý vzorový případ.
Fajn... dej lepsi.
https://www.sqlite.org/src/file?name=src/bitvec.c&ci=tip
https://github.com/jupyter/notebook/blob/master/notebook/utils.py
https://github.com/servo/servo/blob/master/components/selectors/bloom.rs
https://doc.rust-lang.org/src/core/fmt/mod.rs.html
-
Takze me nezajima to co tam "je", ale to co ti tam chybi....
Zajimaly by me ty "zakladni informace".
Nejakej dobre priklad kde to je a kde je to fakt uzitecny...
Co sem si vsimnul tak vetsina barevnych schemat do IDE a editoru se snazi nejak potlacit komentare aby nebyli tolik videt.
Rikam si... procpak asi?
Základ jsou docstringy k metodám a třídám. U parseru jsem jasně psal, že bych chtěl vědět, co parsuje, ideálně proč je to tam naprasené natvrdo namísto použití nějaké osvědčené metody vytváření parserů.
U komentářů výše jasně píšu, že za normálních okolností jsou šum - když se člověk v nějakém kódu pohybuje denně. Pokud něco nemáš v hlavě a z kódu to snadno nevyčteš, je z šumu rázem signál. To je asi tak odpověď na Tvoje dvě otázky - proč jsou komentáře a proč jsou komentáře vizuálně potlačeny.
Všechno to v diskusi už zaznělo.
-
Hele, fakt nechci rýpat, ale tohle mi nepřijde jako dobrý vzorový případ.
Fajn... dej lepsi.
https://www.sqlite.org/src/file?name=src/bitvec.c&ci=tip
https://github.com/jupyter/notebook/blob/master/notebook/utils.py
https://github.com/servo/servo/blob/master/components/selectors/bloom.rs
https://doc.rust-lang.org/src/core/fmt/mod.rs.html
Ten BloomFilter je krasnej priklad...
Cekal sem, ze si prectu komentar a budu chapat co to teda treba filtruje a proc to neco pocita.... ale nemam paru...
Jsem prehlcen nejakymi implementacnim detaily a kontext nemam stejne zadnej....
Stejny jako v tom fitnesse... Taky kdyz nahodne nekam kouknu nevim nic...
v Utils.py se mi nejvic libi komentar:
def url_is_absolute(url):
"""Determine whether a given URL is absolute"""
-
Takze me nezajima to co tam "je", ale to co ti tam chybi....
Zajimaly by me ty "zakladni informace".
Nejakej dobre priklad kde to je a kde je to fakt uzitecny...
Co sem si vsimnul tak vetsina barevnych schemat do IDE a editoru se snazi nejak potlacit komentare aby nebyli tolik videt.
Rikam si... procpak asi?
Základ jsou docstringy k metodám a třídám. U parseru jsem jasně psal, že bych chtěl vědět, co parsuje, ideálně proč je to tam naprasené natvrdo namísto použití nějaké osvědčené metody vytváření parserů.
Mas nejakej priklad s tim parserem?
U komentářů výše jasně píšu, že za normálních okolností jsou šum - když se člověk v nějakém kódu pohybuje denně. Pokud něco nemáš v hlavě a z kódu to snadno nevyčteš, je z šumu rázem signál. To je asi tak odpověď na Tvoje dvě otázky - proč jsou komentáře a proč jsou komentáře vizuálně potlačeny.
Všechno to v diskusi už zaznělo.
To znamena, ze za normalnich okolnosti jsou komentare na obtiz?
Takze pisu komentare kvuli nenormalnim okolnostem protoze me to jednou vytahne z bryndy, i kdyz vim, ze se kvuli tomu musim denno denne brodit sumem?
-
To znamena, ze za normalnich okolnosti jsou komentare na obtiz?
Takze pisu komentare kvuli nenormalnim okolnostem protoze me to jednou vytahne z bryndy, i kdyz vim, ze se kvuli tomu musim denno denne brodit sumem?
Ano, je to podobné jako s pásy v autě, se zdravotním pojištěním nebo znalostí logaritmů. Je to opruz, většinu života je to úplně na nic, ale holt se to hodí.
-
Základ jsou docstringy k metodám a třídám.
K čemu jsou docstringy, když mám parametry i návratové hodnoty řádně otypovány?
-
Základ jsou docstringy k metodám a třídám.
K čemu jsou docstringy, když mám parametry i návratové hodnoty řádně otypovány?
Prosím už nereaguj, děkuju.
-
To znamena, ze za normalnich okolnosti jsou komentare na obtiz?
Takze pisu komentare kvuli nenormalnim okolnostem protoze me to jednou vytahne z bryndy, i kdyz vim, ze se kvuli tomu musim denno denne brodit sumem?
Ano, je to podobné jako s pásy v autě, se zdravotním pojištěním nebo znalostí logaritmů. Je to opruz, většinu života je to úplně na nic, ale holt se to hodí.
Spatna analogie...
Pasy v aute jsou ze zakona povinne... Zdravotni pojisteni taky. Psani komentaru ne.
Znalost logaritmu nepovazuju za obtezujici.
-
v Utils.py se mi nejvic libi komentar:
def url_is_absolute(url):
"""Determine whether a given URL is absolute"""
Jsou tam i jiné výživné komponenty
try:
os.lstat(path)
except OSError:
return False
return True
-
U komentářů výše jasně píšu, že za normálních okolností jsou šum - když se člověk v nějakém kódu pohybuje denně. Pokud něco nemáš v hlavě a z kódu to snadno nevyčteš, je z šumu rázem signál. To je asi tak odpověď na Tvoje dvě otázky - proč jsou komentáře a proč jsou komentáře vizuálně potlačeny.
Všechno to v diskusi už zaznělo.
To znamena, ze za normalnich okolnosti jsou komentare na obtiz?
Takze pisu komentare kvuli nenormalnim okolnostem protoze me to jednou vytahne z bryndy, i kdyz vim, ze se kvuli tomu musim denno denne brodit sumem?
Komentáře by nebyly na obtíž, kdyby to skutečně byly komentáře. V drtivé většině případů jsou však jen šumem, který zhoršuje čitelnost kódu. Proto je třeba je potlačit.
-
Komentar v kodu beru jako svoje selhani pri snaze napsat sebevysvetlujici kod. Snazim se jich mit co nejmin a ostatni k tomu nabadam taky.
Osvedcilo se mi to.
No tak si to užij. Akorát si dovolím podotknout, že tady nikdo netvrdil, že kód má být nepřehledný a že komentář je od toho, aby to kompenzoval.
Taky sem nerekl, ze to nekdo tvrdil. byla to reakce na to ze "komentujeme hodne". To mi rika, ze je neco spatne....
EDIT: Muzes sem treba dat kus kodu, ktery podle tebe vyzaduje byti hodne okomentovan. Rad bych ho videl.
Tady je treba kousek kodu, ktery by si okomentovani zaslouzil:
function [lambdaMax, nullMSE] = computeLambdaMax(X, Y, weights, alpha, standardize)
if ~isempty(weights)
observationWeights = true;
weights = weights(:)';
normalizedweights = weights / sum(weights);
else
observationWeights = false;
end
[N,~] = size(X);
if standardize
constantPredictors = (range(X)==0);
if ~observationWeights
[X0,~,~] = zscore(X,1);
else
muX = normalizedweights * X;
X0 = bsxfun(@minus,X,muX);
sigmaX = sqrt( normalizedweights * (X0.^2) );
sigmaX(constantPredictors) = 1;
X0 = bsxfun(@rdivide, X0, sigmaX);
end
else
if ~observationWeights
muX = mean(X,1);
X0 = bsxfun(@minus,X,muX);
else
muX = normalizedweights(:)' * X;
X0 = bsxfun(@minus,X,muX);
end
end
if observationWeights
wX0 = bsxfun(@times, X0, weights');
end
if ~observationWeights
muY = mean(Y);
else
muY = weights*Y;
end
Y0 = Y - muY;
if ~observationWeights
dotp = abs(X0' * Y0);
lambdaMax = max(dotp) / (N*alpha);
else
dotp = abs(sum(bsxfun(@times, wX0, Y0)));
lambdaMax = max(dotp) / alpha;
end
if ~observationWeights
nullMSE = mean(Y0.^2);
else
nullMSE = weights * (Y0.^2);
end
end
-
Komentar v kodu beru jako svoje selhani pri snaze napsat sebevysvetlujici kod. Snazim se jich mit co nejmin a ostatni k tomu nabadam taky.
Osvedcilo se mi to.
No tak si to užij. Akorát si dovolím podotknout, že tady nikdo netvrdil, že kód má být nepřehledný a že komentář je od toho, aby to kompenzoval.
Taky sem nerekl, ze to nekdo tvrdil. byla to reakce na to ze "komentujeme hodne". To mi rika, ze je neco spatne....
EDIT: Muzes sem treba dat kus kodu, ktery podle tebe vyzaduje byti hodne okomentovan. Rad bych ho videl.
Tady je treba kousek kodu, ktery by si okomentovani zaslouzil:
function [lambdaMax, nullMSE] = computeLambdaMax(X, Y, weights, alpha, standardize)
if ~isempty(weights)
observationWeights = true;
weights = weights(:)';
normalizedweights = weights / sum(weights);
else
observationWeights = false;
end
[N,~] = size(X);
if standardize
constantPredictors = (range(X)==0);
if ~observationWeights
[X0,~,~] = zscore(X,1);
else
muX = normalizedweights * X;
X0 = bsxfun(@minus,X,muX);
sigmaX = sqrt( normalizedweights * (X0.^2) );
sigmaX(constantPredictors) = 1;
X0 = bsxfun(@rdivide, X0, sigmaX);
end
else
if ~observationWeights
muX = mean(X,1);
X0 = bsxfun(@minus,X,muX);
else
muX = normalizedweights(:)' * X;
X0 = bsxfun(@minus,X,muX);
end
end
if observationWeights
wX0 = bsxfun(@times, X0, weights');
end
if ~observationWeights
muY = mean(Y);
else
muY = weights*Y;
end
Y0 = Y - muY;
if ~observationWeights
dotp = abs(X0' * Y0);
lambdaMax = max(dotp) / (N*alpha);
else
dotp = abs(sum(bsxfun(@times, wX0, Y0)));
lambdaMax = max(dotp) / alpha;
end
if ~observationWeights
nullMSE = mean(Y0.^2);
else
nullMSE = weights * (Y0.^2);
end
end
Me prijde, ze by si spis zaslouzil smazat.... :-)
-
...
Me prijde, ze by si spis zaslouzil smazat.... :-)
Teď jsem to chtěl napsat, ale předběhl jsi mne. Je to fakt hnus.
-
Komentar v kodu beru jako svoje selhani pri snaze napsat sebevysvetlujici kod. Snazim se jich mit co nejmin a ostatni k tomu nabadam taky.
Osvedcilo se mi to.
No tak si to užij. Akorát si dovolím podotknout, že tady nikdo netvrdil, že kód má být nepřehledný a že komentář je od toho, aby to kompenzoval.
Taky sem nerekl, ze to nekdo tvrdil. byla to reakce na to ze "komentujeme hodne". To mi rika, ze je neco spatne....
EDIT: Muzes sem treba dat kus kodu, ktery podle tebe vyzaduje byti hodne okomentovan. Rad bych ho videl.
Tady je treba kousek kodu, ktery by si okomentovani zaslouzil:
function [lambdaMax, nullMSE] = computeLambdaMax(X, Y, weights, alpha, standardize)
if ~isempty(weights)
observationWeights = true;
weights = weights(:)';
normalizedweights = weights / sum(weights);
else
observationWeights = false;
end
[N,~] = size(X);
if standardize
constantPredictors = (range(X)==0);
if ~observationWeights
[X0,~,~] = zscore(X,1);
else
muX = normalizedweights * X;
X0 = bsxfun(@minus,X,muX);
sigmaX = sqrt( normalizedweights * (X0.^2) );
sigmaX(constantPredictors) = 1;
X0 = bsxfun(@rdivide, X0, sigmaX);
end
else
if ~observationWeights
muX = mean(X,1);
X0 = bsxfun(@minus,X,muX);
else
muX = normalizedweights(:)' * X;
X0 = bsxfun(@minus,X,muX);
end
end
if observationWeights
wX0 = bsxfun(@times, X0, weights');
end
if ~observationWeights
muY = mean(Y);
else
muY = weights*Y;
end
Y0 = Y - muY;
if ~observationWeights
dotp = abs(X0' * Y0);
lambdaMax = max(dotp) / (N*alpha);
else
dotp = abs(sum(bsxfun(@times, wX0, Y0)));
lambdaMax = max(dotp) / alpha;
end
if ~observationWeights
nullMSE = mean(Y0.^2);
else
nullMSE = weights * (Y0.^2);
end
end
Me prijde, ze by si spis zaslouzil smazat.... :-)
Jasny, kdyz nevim, co to dela, tak to smazu :-))
-
Sebevysvetlujici kod v dlouhodobe vyvijenem projektu je utopie. Jestli nekdo tvrdi, ze se obejde bez komentaru, tak lze, nebo dela jen male veci.
Treba nedavno kolega nasel bug v knihovne spadajicich do "apache commons" (javisti jiste znaji). Tak co se necha udelat. Chyba se reportuje, ale mezitim je potreba do sveho kodu dostat "fix". To jest kus co na prvni pohled nedava smysl a vypada jako prasecina, plus peknych par radku s vysvetlenim vo co go. A takovych situaci se behem let opravdu nasklada mnoho.
-
Me prijde, ze by si spis zaslouzil smazat.... :-)
Jasny, kdyz nevim, co to dela, tak to smazu :-))
Nadsazka....
Chtel by refactoring...
Funce tak na 5 radku tops... a poradny jmena
-
Me prijde, ze by si spis zaslouzil smazat.... :-)
Jasny, kdyz nevim, co to dela, tak to smazu :-))
Nadsazka....
Chtel by refactoring...
Funce tak na 5 radku tops... a poradny jmena
Našel jsem originál napsaný v R a ten ty komentáře má. Ovšem má tam i zcela zbytečnou proměnnou observationWeights, která ten kód tak mlží.
-
Základ jsou docstringy k metodám a třídám.
K čemu jsou docstringy, když mám parametry i návratové hodnoty řádně otypovány?
Ke zdokumentování kódu.
-
Sebevysvetlujici kod v dlouhodobe vyvijenem projektu je utopie. Jestli nekdo tvrdi, ze se obejde bez komentaru, tak lze, nebo dela jen male veci.
Treba nedavno kolega nasel bug v knihovne spadajicich do "apache commons" (javisti jiste znaji). Tak co se necha udelat. Chyba se reportuje, ale mezitim je potreba do sveho kodu dostat "fix". To jest kus co na prvni pohled nedava smysl a vypada jako prasecina, plus peknych par radku s vysvetlenim vo co go. A takovych situaci se behem let opravdu nasklada mnoho.
Tak treba ten fitnesse ma 15 let.... je to dost dlouhodobe?
Komentaru je tam pomalu.
No a ty kousky co tu postoval Ink me nepresvedcili, ze ty komentare jsou extra uzitecne.
A samozrejme... jsou situace kdy proste musis... nikdy sem nerekl, ze komentare nepisu vubec. Jen rikam, ze se to snazim minimalizovat.
Problem komentaru proste je, ze se nekompilujou a netestujou (doctest ted nechme stranou).
Takze pro me nejsou duveryhodne.
-
Základ jsou docstringy k metodám a třídám.
K čemu jsou docstringy, když mám parametry i návratové hodnoty řádně otypovány?
Ke zdokumentování kódu.
O zdokumentování kódu se přece postarají typy a testy.
-
Fajn... dej lepsi.
https://github.com/torvalds/linux/blob/master/block/blk-core.c#L152
Všimni si té věty "Useful in ...", ta je zajímavá, sděluje kontext proč tam ta funkce vůbec je.
Jestli mi někdo bude tvrdit, že rychleji zjistí z kódu, co ta funkce dělá, tak mu prostě nevěřím. Například proto, že nevím, co je v poli blk_op_name uložené. Takže kdyby tam nebyl ten komentář, musím skočit na jeho definici a z ní na definici makra REQ_OP_NAME, pak si budu muset vzpomenout, jak se vlastně nahrazují ty # a ##. A až mi docvakne, jak je to vlastně triviální, musím odskákat zase zpátky. Jasně, klidně mi někdo může tvrdit, že si to z kódu přečte líp než z těch pár řádků komentáře. Nebo že CDS bezvadně léčí rakovinu... Ok, good luck.
-
Sebevysvetlujici kod v dlouhodobe vyvijenem projektu je utopie. Jestli nekdo tvrdi, ze se obejde bez komentaru, tak lze, nebo dela jen male veci.
Treba nedavno kolega nasel bug v knihovne spadajicich do "apache commons" (javisti jiste znaji). Tak co se necha udelat. Chyba se reportuje, ale mezitim je potreba do sveho kodu dostat "fix". To jest kus co na prvni pohled nedava smysl a vypada jako prasecina, plus peknych par radku s vysvetlenim vo co go. A takovych situaci se behem let opravdu nasklada mnoho.
Tak treba ten fitnesse ma 15 let.... je to dost dlouhodobe?
Komentaru je tam pomalu.
No a ty kousky co tu postoval Ink me nepresvedcili, ze ty komentare jsou extra uzitecne.
A samozrejme... jsou situace kdy proste musis... nikdy sem nerekl, ze komentare nepisu vubec. Jen rikam, ze se to snazim minimalizovat.
Problem komentaru proste je, ze se nekompilujou a netestujou (doctest ted nechme stranou).
Takze pro me nejsou duveryhodne.
Jo, patnact aktivnich let je pekny pro SW projekt :) Ja tento projekt teda vubec neznam. Jen na prvni pohled mi to prijde jako mensi vec. Prijde mi ze jeden clovek je schopny cele "pobrat". Nicmene, par komentaru se tam i tak najde. Ono to mozna bude dane i typem projektu. Je to proste jednoucelovy framework a z kontextu veci je jasny jak to funguje a co kod dela.
Jasny, komentare maji problem jak si popsal. Nejde automatizovat kontrola jejich spravnosti. Ja beru komentare jako soucast dokumentace kodu (projektu).
-
... Například proto, že nevím, co je v poli blk_op_name uložené. Takže kdyby tam nebyl ten komentář, musím skočit na jeho definici a z ní na definici makra REQ_OP_NAME, pak si budu muset vzpomenout, jak se vlastně nahrazují ty # a ##. A až mi docvakne, jak je to vlastně triviální, musím odskákat zase zpátky. Jasně, klidně mi někdo může tvrdit, že si to z kódu přečte líp než z těch pár řádků komentáře. Nebo že CDS bezvadně léčí rakovinu... Ok, good luck.
Když někdo neumí pojmenovat proměnou, tak je to fakt blbě a v takových případech zpravidla nepomohou ani komentáře.
-
Když někdo neumí pojmenovat proměnou, tak je to fakt blbě a v takových případech zpravidla nepomohou ani komentáře.
Pošli tam pull request s opravou. A poštou trochu CDS. Good luck.
-
Když někdo neumí pojmenovat proměnou, tak je to fakt blbě a v takových případech zpravidla nepomohou ani komentáře.
Pošli tam pull request s opravou. A poštou trochu CDS. Good luck.
Proč bych to dělal? Nejsem vývojářem linuxového jádra. K čemu CDS? Linus ujíždí na savu?
-
Fajn... dej lepsi.
https://github.com/torvalds/linux/blob/master/block/blk-core.c#L152
Všimni si té věty "Useful in ...", ta je zajímavá, sděluje kontext proč tam ta funkce vůbec je.
Jestli mi někdo bude tvrdit, že rychleji zjistí z kódu, co ta funkce dělá, tak mu prostě nevěřím. Například proto, že nevím, co je v poli blk_op_name uložené. Takže kdyby tam nebyl ten komentář, musím skočit na jeho definici a z ní na definici makra REQ_OP_NAME, pak si budu muset vzpomenout, jak se vlastně nahrazují ty # a ##. A až mi docvakne, jak je to vlastně triviální, musím odskákat zase zpátky. Jasně, klidně mi někdo může tvrdit, že si to z kódu přečte líp než z těch pár řádků komentáře. Nebo že CDS bezvadně léčí rakovinu... Ok, good luck.
Nemuze to byt tim, ze C je prilis low level a postrada expresivitu vyssich jazyku?
Od skoly sem v nem nic nepsal ani necet a to uz je davno takze tady se nemuzu moc vyjadrovat.
-
Nemuze to byt tim, ze C je prilis low level a postrada expresivitu vyssich jazyku?
Od skoly sem v nem nic nepsal ani necet a to uz je davno takze tady se nemuzu moc vyjadrovat.
To není tím. Ať mi někdo vysvětlí, proč tohle nejde napsat slušněji i v tom C:
printk(KERN_INFO "%s: dev %s: flags=%llx\n", msg,
rq->rq_disk ? rq->rq_disk->disk_name : "?",
(unsigned long long) rq->cmd_flags);
Jen takový pokus:
device = rq->rq_disk ? rq->rq_disk->disk_name : "?";
flags = (unsigned long long) rq->cmd_flags;
printk(KERN_INFO "%s: dev %s: flags=%llx\n", msg, device, flags);
Kompilací vznikne shodný kód, ale přidáním názvů proměnných se zvýší čitelnost pro lidi.
-
... Například proto, že nevím, co je v poli blk_op_name uložené. Takže kdyby tam nebyl ten komentář, musím skočit na jeho definici a z ní na definici makra REQ_OP_NAME, pak si budu muset vzpomenout, jak se vlastně nahrazují ty # a ##. A až mi docvakne, jak je to vlastně triviální, musím odskákat zase zpátky. Jasně, klidně mi někdo může tvrdit, že si to z kódu přečte líp než z těch pár řádků komentáře. Nebo že CDS bezvadně léčí rakovinu... Ok, good luck.
Když někdo neumí pojmenovat proměnou, tak je to fakt blbě a v takových případech zpravidla nepomohou ani komentáře.
Tak abychom jen tak neteoretizovali, tak jaké jméno by bylo lepší? Že je to nějaký "Block Operation String" je z té zkratky IMO jasné i bez dalšího kontextu? Jak byste to pojmenoval vy?
-
Nemuze to byt tim, ze C je prilis low level a postrada expresivitu vyssich jazyku?
Od skoly sem v nem nic nepsal ani necet a to uz je davno takze tady se nemuzu moc vyjadrovat.
To není tím. Ať mi někdo vysvětlí, proč tohle nejde napsat slušněji i v tom C:
printk(KERN_INFO "%s: dev %s: flags=%llx\n", msg,
rq->rq_disk ? rq->rq_disk->disk_name : "?",
(unsigned long long) rq->cmd_flags);
Jen takový pokus:
device = rq->rq_disk ? rq->rq_disk->disk_name : "?";
flags = (unsigned long long) rq->cmd_flags;
printk(KERN_INFO "%s: dev %s: flags=%llx\n", msg, device, flags);
Kompilací vznikne shodný kód, ale přidáním názvů proměnných se zvýší čitelnost pro lidi.
Fakt to o tolik zlepší čitelnost? Máme takřka identické řádky kódu, akorát v jiném pořadí. Hinty jako "disk_name" nebo "flags" jsou v obou verzích.
Třeba název "device" je tak obecný, že říká ještě míň než to "disk_name". Mohl bych tu proměnnou přejmenovat na temp a věděl bych furt to samé, protože bez té pravé strany z názvu "device" taky moc nevydedukuju.
-
Základ jsou docstringy k metodám a třídám.
K čemu jsou docstringy, když mám parametry i návratové hodnoty řádně otypovány?
Ke zdokumentování kódu.
O zdokumentování kódu se přece postarají typy a testy.
Nepostarají.
-
Nemuze to byt tim, ze C je prilis low level a postrada expresivitu vyssich jazyku?
Ne. Protože vyšší expresivita by jenom znamenala, že tam bude víc vrstev abstrakce. Takže pokud bych chtěl zjistit, co ta funkce opravdu dělá, musel bych jenom projít víc vrstev (pokud nebudou okomentované). Čili ještě horší situace. Ten FizBuzz Enterprise Edition je výborný příklad.
Kompilací vznikne shodný kód, ale přidáním názvů proměnných se zvýší čitelnost pro lidi.
<rýpací mód>
Ne, nevznikne, protože ten tvůj kód se vůbec nezkompiluje, páč je nevalidní :)
</rýpací mód>
-
Nemuze to byt tim, ze C je prilis low level a postrada expresivitu vyssich jazyku?
Ne. Protože vyšší expresivita by jenom znamenala, že tam bude víc vrstev abstrakce.
Však to je správně, na vyšší úrovni se věci chápou lépe, už jen C je abstrakce nad asemblerem, tak nízko se nikdo nerýpe.
-
Nemuze to byt tim, ze C je prilis low level a postrada expresivitu vyssich jazyku?
Ne. Protože vyšší expresivita by jenom znamenala, že tam bude víc vrstev abstrakce. Takže pokud bych chtěl zjistit, co ta funkce opravdu dělá, musel bych jenom projít víc vrstev (pokud nebudou okomentované).
Nebo pojmenovane, otypovane, pokryte testy
Ten FizBuzz Enterprise Edition je výborný příklad.
Ceho?
-
Však to je správně, na vyšší úrovni se věci chápou lépe, už jen C je abstrakce nad asemblerem, tak nízko se nikdo nerýpe.
Bavíme se o situaci bez komentářů. Několik vrstev abstrakce bez komentářů, proč tam která vrstva je a jakou má zodpovědnost, je naprostá tragédie.
Nebo pojmenovane, otypovane, pokryte testy
To je samozřejmost.
Ten FizBuzz Enterprise Edition je výborný příklad.
Ceho?
Kódu, kde když chci zjistit, co dělá nějaká funkce, musím projít desítky souborů.
-
Však to je správně, na vyšší úrovni se věci chápou lépe, už jen C je abstrakce nad asemblerem, tak nízko se nikdo nerýpe.
Bavíme se o situaci bez komentářů. Několik vrstev abstrakce bez komentářů, proč tam která vrstva je a jakou má zodpovědnost, je naprostá tragédie.
To je docela zajímavý argument, to s tím C jako abstrakcí. Nevím jak ty (@Idris), ale když by si poprvé viděl konstrukci:
for (i=1;i<61 && feof(h);i++) {...}Věděl by si co ta konstrukce for() {} dělá, jen na základě její samopopisnosti? Aniž by si znal konstrukci &&? Aniž by si znal co znamená EOF? etc?
-
Aniž by si znal konstrukci &&? Aniž by si znal co znamená EOF? etc?
produkcni kod neni ucebnice programovani pro zacatecniky.
-
Aniž by si znal konstrukci &&? Aniž by si znal co znamená EOF? etc?
produkcni kod neni ucebnice programovani pro zacatecniky.
Vypadá to, že jsi nepochopil pointu mého přirovnání :-)
-
Však to je správně, na vyšší úrovni se věci chápou lépe, už jen C je abstrakce nad asemblerem, tak nízko se nikdo nerýpe.
Bavíme se o situaci bez komentářů. Několik vrstev abstrakce bez komentářů, proč tam která vrstva je a jakou má zodpovědnost, je naprostá tragédie.
To je docela zajímavý argument, to s tím C jako abstrakcí. Nevím jak ty (@Idris), ale když by si poprvé viděl konstrukci:
for (i=1;i<61 && feof(h);i++) {...}Věděl by si co ta konstrukce for() {} dělá, jen na základě její samopopisnosti? Aniž by si znal konstrukci &&? Aniž by si znal co znamená EOF? etc?
Klíčové slovo for, závorky, && a další symboly jsou jazykovými konstrukty, které znát musíš, pokud chceš pracovat s C. Jediným neznámým prvkem by mohla být funkce feof(), která není součástí jazyka, ale jeho knihovny stdio.
-
To je docela zajímavý argument, to s tím C jako abstrakcí. Nevím jak ty (@Idris), ale když by si poprvé viděl konstrukci:
for (i=1;i<61 && feof(h);i++) {...}Věděl by si co ta konstrukce for() {} dělá, jen na základě její samopopisnosti? Aniž by si znal konstrukci &&? Aniž by si znal co znamená EOF? etc?
Nevím, kam míříš, ale samozřejmě, že nevěděl. Stejně jako třeba ty asi nebudeš rozumět větě "Flyg vilda fågel, flyg du som kan".
A?
-
To je docela zajímavý argument, to s tím C jako abstrakcí. Nevím jak ty (@Idris), ale když by si poprvé viděl konstrukci:
for (i=1;i<61 && feof(h);i++) {...}Věděl by si co ta konstrukce for() {} dělá, jen na základě její samopopisnosti? Aniž by si znal konstrukci &&? Aniž by si znal co znamená EOF? etc?
Nevím, kam míříš, ale samozřejmě, že nevěděl. Stejně jako třeba ty asi nebudeš rozumět větě "Flyg vilda fågel, flyg du som kan".
A?
Že sice @Idris má pravdu v tom, že do nižších abstrakcí se nešťourá, na druhou stranu jen se samopopisností si nevystačím.
Když prostě nějakou hromadu asembleru nahradím za for() {} tak je to super, ale jen v případě, kdy někde vysvětlím, co ta konstrukce dělá. Jinak je to opravdu "Flyg vilda fågel, flyg du som kan".
Příklad s tím for je pěkný i v tom, že jasně ukazuje jak to zřejmě má fungovat. Jsou to tři písmenka, pro angličtináře nesou význam - což opět pomáhá. Ten význam sám o sobě nic nevysvětlí - na to je třeba nějaká definice, ale pomůže v tom se zorientovat. A hlavně jsou dostatečně krátká, aby nevznikal šum.
IMHO podobně by to tedy mělo fungovat i dál: pojmenování symbolu by mělo být krátké tak aby nevznikal šum, ale ne příliš, aby to člověku, který to bude číst pomohlo se v tom zorientovat - aby nemusel skákat na definici. A ta lidská definice tam musí být také, protože z toho vlastního pojmenování to obvykle stačit nebude - páč jinak by se to zvrhlo zase v dlouhý název, který bude ale zase nepříjemný na použití.
-
IMHO podobně by to tedy mělo fungovat i dál: pojmenování symbolu by mělo být krátké tak aby nevznikal šum, ale ne příliš, aby to člověku, který to bude číst pomohlo se v tom zorientovat - aby nemusel skákat na definici. A ta lidská definice tam musí být také, protože z toho vlastního pojmenování to obvykle stačit nebude - páč jinak by se to zvrhlo zase v dlouhý název, který bude ale zase nepříjemný na použití.
Lokální symboly mají být krátké, ideálně jednoslovní. U globálních symbolů s tím nevystačíme, proto používáme slepence podle různých notací (např. v C) nebo v moderních jazycích s pomocí namespace. Zásadou je nepoužívat zkráceniny, ale pro řídicí proměnné cyklu se názvy i, j, k tak zažily, že je zbytečné proti nim bojovat.
-
Možná bych se ještě doplnil, že často může pomoct využití kontextu, kdy třeba v rámci nějaké lokálního cyklu nebudu řešit, že ty elementy jsou třeba user, ale budu řešit jejich smysl pojmenování v rámci toho kontextu: first, tail, případně dokonce x v případě, kdy proměnná nemá žádný význam. Pak se někdy opravdu povede bez toho komentáře obejít.
-
Když prostě nějakou hromadu asembleru nahradím za for() {} tak je to super, ale jen v případě, kdy někde vysvětlím, co ta konstrukce dělá. Jinak je to opravdu "Flyg vilda fågel, flyg du som kan".
Jo. A taky musí mít ta abstrakce nějakou zřejmou, snadno uchopitelnou logiku. Když zavedeš operátor, kterej bude občas sčítat, občas násobit a sem tam program shodí, ale jenom ve tři hodiny odpoledne, tak to bude taky na prd :)
(P.S. tak mě napadá, v JS určitě takový operátor je, ne? Divil bych se, kdyby nebyl, to by byla první příležitost něco zvorat, kterou by JS nevyužilo ;) )
Příklad s tím for je pěkný i v tom, že jasně ukazuje jak to zřejmě má fungovat. Jsou to tři písmenka, pro angličtináře nesou význam - což opět pomáhá. Ten význam sám o sobě nic nevysvětlí - na to je třeba nějaká definice, ale pomůže v tom se zorientovat. A hlavně jsou dostatečně krátká, aby nevznikal šum.
Tak ideálně by krátký měly být věci, který používáš nejčastěji. Ne zhovadilý "function", ale radši "func" a úplně ideálně "fn" :)
A ta lidská definice tam musí být také, protože z toho vlastního pojmenování to obvykle stačit nebude - páč jinak by se to zvrhlo zase v dlouhý název, který bude ale zase nepříjemný na použití.
Vidím to úplně stejně.
-
Tak ideálně by krátký měly být věci, který používáš nejčastěji. Ne zhovadilý "function", ale radši "func" a úplně ideálně "fn" :)
Jazyk C šel se zkracováním ještě dál a nedává tam nic.
-
IMHO podobně by to tedy mělo fungovat i dál: pojmenování symbolu by mělo být krátké tak aby nevznikal šum, ale ne příliš, aby to člověku, který to bude číst pomohlo se v tom zorientovat - aby nemusel skákat na definici. A ta lidská definice tam musí být také, protože z toho vlastního pojmenování to obvykle stačit nebude - páč jinak by se to zvrhlo zase v dlouhý název, který bude ale zase nepříjemný na použití.
Lokální symboly mají být krátké, ideálně jednoslovní. U globálních symbolů s tím nevystačíme, proto používáme slepence podle různých notací (např. v C) nebo v moderních jazycích s pomocí namespace. Zásadou je nepoužívat zkráceniny, ale pro řídicí proměnné cyklu se názvy i, j, k tak zažily, že je zbytečné proti nim bojovat.
Proč by mělo být zásadou nepoužívat zkráceniny? Takové "cnt", "tmp", "inc", "dec" myslím pochopí každý. Co třeba "rem" nebo "dir"? Pokud se někde u cyklu vyskytne "n", tak taky každý pochopí. "x" a "y" jsou zažité matematické konvence. Pokud píšu třeba porovnání nebo nějakou podobnou symetrickou operaci, tak "a" a "b" bohatě stačí.
Zažitých zkratek jsou tisíce, nejen to i j k. Rozepsat nějakou zažitou zkratku čtenáři kódu žádnou dodatečnou informaci nedodá.
-
Aniž by si znal konstrukci &&? Aniž by si znal co znamená EOF? etc?
produkcni kod neni ucebnice programovani pro zacatecniky.
Vypadá to, že jsi nepochopil pointu mého přirovnání :-)
jo, necetl jsem celou diskuzi.
-
Jazyk C šel se zkracováním ještě dál a nedává tam nic.
musíš tam uviesť typ návratovej hodnoty (čo je tiež riadna otrava) moderné jazyky, ktoré používajú Hindley-Milner typový systém si vedia v 99% typ odvodiť automaticky (a tam kde si nevedia sa použije typová anotácia)
mne sa páči jeden príkaz na všetko tak ako to majú ML jazyky napr let:
let x = 5 // (ne)premenná "x" inicializovaná hodnotou 5let add a b = a + b // funkcia add s dvomi parametrami x a y
-
musíš tam uviesť typ návratovej hodnoty (čo je tiež riadna otrava) moderné jazyky, ktoré používajú Hindley-Milner typový systém si vedia v 99% typ odvodiť automaticky (a tam kde si nevedia sa použije typová anotácia)
Nemůžeš porovnávat C s moderními jazyky. Tenkrát byla potřebná efektivní nadstavba nad assemblerem tak, aby se nemusel pro každý procesor psát program znovu, což bylo splněno. Tehdejší výkon procesorů by na dnešní jazyky asi nestačil.
Škoda jen, že na Fortran se tak nějak pozapomnělo. Už tenkrát měl mnohé, čím se holedbají moderní jazyky.
-
a ze pak lze vytvaret hierarchii potomku a usetrit si tak psani kodu.
Code reuse dědičností se považuje za antipattern.
Inheritance, if you look at it with a very jaded eye, inheritance is the declaration of methods and variables in a subscope and it has nothing to do with ISA whatever. :)
Je to o úhlu pohledu. Tohle má moje větší sympatie.
-
Inheritance, if you look at it with a very jaded eye, inheritance is the declaration of methods and variables in a subscope and it has nothing to do with ISA whatever. :)
Je to o úhlu pohledu. Tohle má moje větší sympatie.
Ano, tenhle pohled dělá z dogmatického přístupu k OOP ("modelování reálného světa" typu "kameni, leť!") inženýrský přístup.
-
a ze pak lze vytvaret hierarchii potomku a usetrit si tak psani kodu.
Code reuse dědičností se považuje za antipattern.
Inheritance, if you look at it with a very jaded eye, inheritance is the declaration of methods and variables in a subscope and it has nothing to do with ISA whatever. :)
Je to o úhlu pohledu. Tohle má moje větší sympatie.
Vsak to IS-A v OOP světě znamená kompatibilní parametry, návratové hodnoty a invarianty. Tvrzení o nějakých zásadních podobnostech s objekty reálného světa patří tak do říše pohádek pro korporátní konzultanty.
Pokud má předek smysl sám o sobě, tak by potomek neměl nějak zákeřně měnit chování. To vlastně nevychází přímo z dědičnosti. Je to IMO důsledek nenápadného implicitního přetypování. Pokud toho přetypování dosáhnu jinak (třeba operátorem přetypování v c++), tak mám vlastně úplně stejnou situaci.