Fórum Root.cz

Hlavní témata => Vývoj => Téma založeno: Sirdhemond 10. 06. 2020, 17:21:09

Název: Abstrakce u OOP
Přispěvatel: 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?
Název: Re:Abstrakce u OOP
Přispěvatel: alex6bbc 10. 06. 2020, 17:38:59
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.
Název: Re:Abstrakce u OOP
Přispěvatel: Ondrej Nemecek 10. 06. 2020, 17:54:41
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:

Kód: [Vybrat]
// 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);


Kód: [Vybrat]
// 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.
Název: Re:Abstrakce u OOP
Přispěvatel: Idris 10. 06. 2020, 18:11:41
a ze pak lze vytvaret hierarchii potomku a usetrit si tak psani kodu.
Code reuse dědičností se považuje za antipattern.
Název: Re:Abstrakce u OOP
Přispěvatel: Idris 10. 06. 2020, 18:13:48
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).
Název: Re:Abstrakce u OOP
Přispěvatel: AgentK 10. 06. 2020, 19:07:26
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. :-)
Název: Re:Abstrakce u OOP
Přispěvatel: alex6bbc 10. 06. 2020, 19:13:03
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.
Název: Re:Abstrakce u OOP
Přispěvatel: alex6bbc 10. 06. 2020, 19:16:14
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.
Název: Re:Abstrakce u OOP
Přispěvatel: Kit 10. 06. 2020, 19:32:41
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.
Název: Re:Abstrakce u OOP
Přispěvatel: BoneFlute 10. 06. 2020, 20:05:13
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.
Název: Re:Abstrakce u OOP
Přispěvatel: A.P.Hacker 10. 06. 2020, 20:31:29
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ří?
Název: Re:Abstrakce u OOP
Přispěvatel: BoneFlute 10. 06. 2020, 20:45:38
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.
Název: Re:Abstrakce u OOP
Přispěvatel: Jiří Havel 10. 06. 2020, 20:52:15
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í.
Název: Re:Abstrakce u OOP
Přispěvatel: BoneFlute 10. 06. 2020, 20:52:26
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.
Název: Re:Abstrakce u OOP
Přispěvatel: BoneFlute 10. 06. 2020, 20:55:15
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.
Název: Re:Abstrakce u OOP
Přispěvatel: Jiří Havel 10. 06. 2020, 21:15:11
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++ :
Kód: [Vybrat]
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.
Název: Re:Abstrakce u OOP
Přispěvatel: alex6bbc 10. 06. 2020, 21:34:02
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.
Název: Re:Abstrakce u OOP
Přispěvatel: Idris 10. 06. 2020, 21:41:38
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.
Název: Re:Abstrakce u OOP
Přispěvatel: Idris 10. 06. 2020, 21:45:40
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++ :
Kód: [Vybrat]
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é...
Název: Re:Abstrakce u OOP
Přispěvatel: Jiří Havel 10. 06. 2020, 22:15:59
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í.
Název: Re:Abstrakce u OOP
Přispěvatel: Ink 11. 06. 2020, 08:42:29
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.)?
Název: Re:Abstrakce u OOP
Přispěvatel: Idris 11. 06. 2020, 09:04:31
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.
Název: Re:Abstrakce u OOP
Přispěvatel: Ink 11. 06. 2020, 10:33:35
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.
Název: Re:Abstrakce u OOP
Přispěvatel: Kit 11. 06. 2020, 11:52:33
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.
Název: Re:Abstrakce u OOP
Přispěvatel: Standa Blábol 11. 06. 2020, 12:16:30
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.

Název: Re:Abstrakce u OOP
Přispěvatel: A.P.Hacker 11. 06. 2020, 12:29:26
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.
Název: Re:Abstrakce u OOP
Přispěvatel: Kit 11. 06. 2020, 12:35:32
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í.
Název: Re:Abstrakce u OOP
Přispěvatel: Ondrej Nemecek 11. 06. 2020, 12:36:59
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.
Název: Re:Abstrakce u OOP
Přispěvatel: A.P.Hacker 11. 06. 2020, 12:43:36
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.
Název: Re:Abstrakce u OOP
Přispěvatel: A.P.Hacker 11. 06. 2020, 12:45:01
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.
Název: Re:Abstrakce u OOP
Přispěvatel: Jiří Havel 11. 06. 2020, 12:52:53
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í.
Název: Re:Abstrakce u OOP
Přispěvatel: A.P.Hacker 11. 06. 2020, 13:02:26
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.
Název: Re:Abstrakce u OOP
Přispěvatel: Jiří Havel 11. 06. 2020, 13:03:17
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.
Název: Re:Abstrakce u OOP
Přispěvatel: Jiří Havel 11. 06. 2020, 13:30:48
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.
Název: Re:Abstrakce u OOP
Přispěvatel: Ink 11. 06. 2020, 15:28:10
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ů.
Název: Re:Abstrakce u OOP
Přispěvatel: A.P.Hacker 11. 06. 2020, 16:01:55
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
Název: Re:Abstrakce u OOP
Přispěvatel: Kit 11. 06. 2020, 16:02:55
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é.
Název: Re:Abstrakce u OOP
Přispěvatel: Ink 11. 06. 2020, 16:12:34
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.
Název: Re:Abstrakce u OOP
Přispěvatel: Kit 11. 06. 2020, 16:46:38
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?
Název: Re:Abstrakce u OOP
Přispěvatel: Jiří Havel 11. 06. 2020, 17:32:48
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? ;)
Název: Re:Abstrakce u OOP
Přispěvatel: BoneFlute 11. 06. 2020, 18:53:01
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.
Název: Re:Abstrakce u OOP
Přispěvatel: A.P.Hacker 11. 06. 2020, 19:20:04
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
Název: Re:Abstrakce u OOP
Přispěvatel: BoneFlute 11. 06. 2020, 20:05:57
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í.
Název: Re:Abstrakce u OOP
Přispěvatel: A.P.Hacker 11. 06. 2020, 20:58:30
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
Název: Re:Abstrakce u OOP
Přispěvatel: Kit 11. 06. 2020, 21:26:14
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.
Název: Re:Abstrakce u OOP
Přispěvatel: redustin 11. 06. 2020, 21:43:54
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ů.
Název: Re:Abstrakce u OOP
Přispěvatel: Kit 11. 06. 2020, 21:50:38
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á.
Název: Re:Abstrakce u OOP
Přispěvatel: redustin 11. 06. 2020, 22:36:58
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.
Název: Re:Abstrakce u OOP
Přispěvatel: Mirek Prýmek 12. 06. 2020, 08:03:28
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é).
Název: Re:Abstrakce u OOP
Přispěvatel: Idris 12. 06. 2020, 08:32:50
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í?  ;)
Název: Re:Abstrakce u OOP
Přispěvatel: Mirek Prýmek 12. 06. 2020, 08:47:04
Tohle je pokus o filosofování?  ;)
Jako obvykle :)
Název: Re:Abstrakce u OOP
Přispěvatel: Ink 12. 06. 2020, 09:40:18
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.
Název: Re:Abstrakce u OOP
Přispěvatel: Jiří Havel 12. 06. 2020, 10:32:22
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.
Název: Re:Abstrakce u OOP
Přispěvatel: Idris 12. 06. 2020, 10:42:41
Tohle je pokus o filosofování?  ;)
Jako obvykle :)
Tak rozveď něco zajímavého, třeba literate programming ;)
Název: Re:Abstrakce u OOP
Přispěvatel: Ink 12. 06. 2020, 11:19:12
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.
Název: Re:Abstrakce u OOP
Přispěvatel: Jiří Havel 12. 06. 2020, 11:39:05
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.
Název: Re:Abstrakce u OOP
Přispěvatel: Mirek Prýmek 12. 06. 2020, 11:52:16
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ří? :)
Název: Re:Abstrakce u OOP
Přispěvatel: Idris 12. 06. 2020, 12:55:55
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.
Název: Re:Abstrakce u OOP
Přispěvatel: listoper 12. 06. 2020, 13:06:40
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.
Název: Re:Abstrakce u OOP
Přispěvatel: Ink 12. 06. 2020, 13:10:43
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.
Název: Re:Abstrakce u OOP
Přispěvatel: A.P.Hacker 12. 06. 2020, 13:13:04
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
Název: Re:Abstrakce u OOP
Přispěvatel: listoper 12. 06. 2020, 13:14:09
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.
Název: Re:Abstrakce u OOP
Přispěvatel: Ink 12. 06. 2020, 13:35:38
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.
Název: Re:Abstrakce u OOP
Přispěvatel: Jiří Havel 12. 06. 2020, 13:55:15
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?
Název: Re:Abstrakce u OOP
Přispěvatel: redustin 12. 06. 2020, 13:57:51
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.
Název: Re:Abstrakce u OOP
Přispěvatel: listoper 12. 06. 2020, 14:19:03
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...
Název: Re:Abstrakce u OOP
Přispěvatel: Jiří Havel 12. 06. 2020, 14:30:18
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ě? ;)
Název: Re:Abstrakce u OOP
Přispěvatel: qelurg 12. 06. 2020, 14:33:06
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.
Název: Re:Abstrakce u OOP
Přispěvatel: listoper 12. 06. 2020, 14:35:18
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.
Název: Re:Abstrakce u OOP
Přispěvatel: listoper 12. 06. 2020, 14:39:38
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.
Název: Re:Abstrakce u OOP
Přispěvatel: Jiří Havel 12. 06. 2020, 14:54:47
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.
Název: Re:Abstrakce u OOP
Přispěvatel: listoper 12. 06. 2020, 14:57:13
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.
Název: Re:Abstrakce u OOP
Přispěvatel: Jiří Havel 12. 06. 2020, 15:24:49
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í.
Název: Re:Abstrakce u OOP
Přispěvatel: Ink 12. 06. 2020, 15:32:57
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:


Kód: [Vybrat]
// REFACTOR The fixture path is really the only part of this
Název: Re:Abstrakce u OOP
Přispěvatel: Kit 12. 06. 2020, 15:50:24
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:


Kód: [Vybrat]
// 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.
Název: Re:Abstrakce u OOP
Přispěvatel: Jiří Havel 12. 06. 2020, 15:50:48
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:


Kód: [Vybrat]
// 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.
Název: Re:Abstrakce u OOP
Přispěvatel: listoper 12. 06. 2020, 15:57:29
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 :-)
Název: Re:Abstrakce u OOP
Přispěvatel: Jiří Havel 12. 06. 2020, 16:02:06
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:


Kód: [Vybrat]
// 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.
Název: Re:Abstrakce u OOP
Přispěvatel: listoper 12. 06. 2020, 16:18:49
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:


Kód: [Vybrat]
// 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.
Název: Re:Abstrakce u OOP
Přispěvatel: Jiří Havel 12. 06. 2020, 16:39:47
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:


Kód: [Vybrat]
// 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.
Název: Re:Abstrakce u OOP
Přispěvatel: listoper 12. 06. 2020, 16:50:49
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.
Název: Re:Abstrakce u OOP
Přispěvatel: listoper 12. 06. 2020, 17:09:33
Otevrel sem si spring-boot a nahodne klikal az najdu nejakou tridu a jestli tam bude komentar a co se z nej dozvim:
Kód: [Vybrat]
/**
 * {@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.
Název: Re:Abstrakce u OOP
Přispěvatel: Ink 12. 06. 2020, 17:11:26
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:

Kód: [Vybrat]
// 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:

Kód: [Vybrat]
/* 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.
Název: Re:Abstrakce u OOP
Přispěvatel: listoper 12. 06. 2020, 17:20:09
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:

Kód: [Vybrat]
// 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:

Kód: [Vybrat]
/* 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.
Název: Re:Abstrakce u OOP
Přispěvatel: listoper 12. 06. 2020, 17:30:47
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:

Kód: [Vybrat]
// 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:

Kód: [Vybrat]
/* 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?
Název: Re:Abstrakce u OOP
Přispěvatel: Kit 12. 06. 2020, 17:43:42
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á.
Název: Re:Abstrakce u OOP
Přispěvatel: Ink 12. 06. 2020, 18:37:34
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
Název: Re:Abstrakce u OOP
Přispěvatel: Ink 12. 06. 2020, 18:44:19
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.
Název: Re:Abstrakce u OOP
Přispěvatel: listoper 12. 06. 2020, 19:06:05
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:
Kód: [Vybrat]
def url_is_absolute(url):
    """Determine whether a given URL is absolute"""
Název: Re:Abstrakce u OOP
Přispěvatel: listoper 12. 06. 2020, 19:10:54
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?
Název: Re:Abstrakce u OOP
Přispěvatel: Ink 12. 06. 2020, 19:36:48
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í.
Název: Re:Abstrakce u OOP
Přispěvatel: Kit 12. 06. 2020, 19:39:20
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?
Název: Re:Abstrakce u OOP
Přispěvatel: Ink 12. 06. 2020, 19:48:04
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.
Název: Re:Abstrakce u OOP
Přispěvatel: listoper 12. 06. 2020, 19:50:35
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.
Název: Re:Abstrakce u OOP
Přispěvatel: Kit 12. 06. 2020, 19:51:23
v Utils.py se mi nejvic libi komentar:
Kód: [Vybrat]
def url_is_absolute(url):
    """Determine whether a given URL is absolute"""

Jsou tam i jiné výživné komponenty
Kód: [Vybrat]
try:
    os.lstat(path)
except OSError:
    return False
return True
Název: Re:Abstrakce u OOP
Přispěvatel: Kit 12. 06. 2020, 20:05:23
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.
Název: Re:Abstrakce u OOP
Přispěvatel: xyz 12. 06. 2020, 20:48:20
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
Název: Re:Abstrakce u OOP
Přispěvatel: listoper 12. 06. 2020, 20:54:22
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.... :-)
Název: Re:Abstrakce u OOP
Přispěvatel: Kit 12. 06. 2020, 21:05:38
...

Me prijde, ze by si spis zaslouzil smazat.... :-)

Teď jsem to chtěl napsat, ale předběhl jsi mne. Je to fakt hnus.
Název: Re:Abstrakce u OOP
Přispěvatel: xyz 12. 06. 2020, 21:11:46
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 :-))
Název: Re:Abstrakce u OOP
Přispěvatel: tomas88 12. 06. 2020, 21:18:50
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.
Název: Re:Abstrakce u OOP
Přispěvatel: listoper 12. 06. 2020, 21:20:02


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
Název: Re:Abstrakce u OOP
Přispěvatel: Kit 12. 06. 2020, 21:24:18


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ží.
Název: Re:Abstrakce u OOP
Přispěvatel: qelurg 12. 06. 2020, 22:13:37
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.
Název: Re:Abstrakce u OOP
Přispěvatel: listoper 12. 06. 2020, 22:15:24
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.

Název: Re:Abstrakce u OOP
Přispěvatel: Kit 12. 06. 2020, 22:20:07
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.
Název: Re:Abstrakce u OOP
Přispěvatel: Mirek Prýmek 12. 06. 2020, 22:44:27
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.
Název: Re:Abstrakce u OOP
Přispěvatel: tomas88 12. 06. 2020, 22:51:44
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).

Název: Re:Abstrakce u OOP
Přispěvatel: Kit 12. 06. 2020, 22:54:04
... 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.
Název: Re:Abstrakce u OOP
Přispěvatel: Mirek Prýmek 12. 06. 2020, 22:58:29
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.
Název: Re:Abstrakce u OOP
Přispěvatel: Kit 12. 06. 2020, 23:09:05
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?
Název: Re:Abstrakce u OOP
Přispěvatel: listoper 12. 06. 2020, 23:19:53
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.
Název: Re:Abstrakce u OOP
Přispěvatel: Kit 13. 06. 2020, 00:02:08

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:
Kód: [Vybrat]
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:
Kód: [Vybrat]
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.
Název: Re:Abstrakce u OOP
Přispěvatel: Jiří Havel 13. 06. 2020, 08:28:30
... 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?
Název: Re:Abstrakce u OOP
Přispěvatel: Jiří Havel 13. 06. 2020, 08:50:21

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:
Kód: [Vybrat]
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:
Kód: [Vybrat]
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.
Název: Re:Abstrakce u OOP
Přispěvatel: qelurg 13. 06. 2020, 08:55:37
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í.
Název: Re:Abstrakce u OOP
Přispěvatel: Mirek Prýmek 13. 06. 2020, 10:46:53
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>
Název: Re:Abstrakce u OOP
Přispěvatel: Idris 13. 06. 2020, 12:18:27
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.
Název: Re:Abstrakce u OOP
Přispěvatel: listoper 13. 06. 2020, 13:49:39
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?
Název: Re:Abstrakce u OOP
Přispěvatel: Mirek Prýmek 13. 06. 2020, 14:52:53
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ů.
Název: Re:Abstrakce u OOP
Přispěvatel: BoneFlute 13. 06. 2020, 16:09:45
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:
Kód: [Vybrat]
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?
Název: Re:Abstrakce u OOP
Přispěvatel: A.P.Hacker 13. 06. 2020, 16:21:08
Aniž by si znal konstrukci &&? Aniž by si znal co znamená EOF? etc?

produkcni kod neni ucebnice programovani pro zacatecniky.
Název: Re:Abstrakce u OOP
Přispěvatel: BoneFlute 13. 06. 2020, 16:26:20
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í :-)
Název: Re:Abstrakce u OOP
Přispěvatel: Kit 13. 06. 2020, 16:35:00
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:
Kód: [Vybrat]
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.
Název: Re:Abstrakce u OOP
Přispěvatel: Mirek Prýmek 13. 06. 2020, 17:03:57
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:
Kód: [Vybrat]
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?
Název: Re:Abstrakce u OOP
Přispěvatel: BoneFlute 13. 06. 2020, 17:15:40
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:
Kód: [Vybrat]
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í.
Název: Re:Abstrakce u OOP
Přispěvatel: Kit 13. 06. 2020, 17:57:53
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.
Název: Re:Abstrakce u OOP
Přispěvatel: BoneFlute 13. 06. 2020, 18:15:29

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.
Název: Re:Abstrakce u OOP
Přispěvatel: Mirek Prýmek 13. 06. 2020, 18:17:03
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ě.
Název: Re:Abstrakce u OOP
Přispěvatel: Kit 13. 06. 2020, 19:30:27
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.
Název: Re:Abstrakce u OOP
Přispěvatel: Jiří Havel 13. 06. 2020, 20:31:25
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á.
Název: Re:Abstrakce u OOP
Přispěvatel: A.P.Hacker 13. 06. 2020, 21:00:54
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.
Název: Re:Abstrakce u OOP
Přispěvatel: fortran1986 13. 06. 2020, 21:29:29
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:

Kód: [Vybrat]
let x = 5 // (ne)premenná "x" inicializovaná hodnotou 5
Kód: [Vybrat]
let add a b = a + b // funkcia add s dvomi parametrami x a y
Název: Re:Abstrakce u OOP
Přispěvatel: Kit 13. 06. 2020, 23:05:05
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.
Název: Re:Abstrakce u OOP
Přispěvatel: Mirek Zvolský 14. 06. 2020, 08:17:50
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.
Název: Re:Abstrakce u OOP
Přispěvatel: Ink 14. 06. 2020, 09:06:50
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.
Název: Re:Abstrakce u OOP
Přispěvatel: Jiří Havel 14. 06. 2020, 12:44:44
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.