Příspěvky

166

Vývoj / Re:Abstrakce u OOP

« kdy: 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.

167

Vývoj / Re:Abstrakce u OOP

« kdy: 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á.

168

Vývoj / Re:Abstrakce u OOP

« kdy: 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.

169

Vývoj / Re:Abstrakce u OOP

« kdy: 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?

170

Vývoj / Re:Abstrakce u OOP

« kdy: 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.

171

Vývoj / Re:Abstrakce u OOP

« kdy: 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.

172

Vývoj / Re:Abstrakce u OOP

« kdy: 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.

173

Vývoj / Re:Abstrakce u OOP

« kdy: 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. 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 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 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í.

174

Vývoj / Re:Abstrakce u OOP

« kdy: 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. 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.

175

Vývoj / Re:Abstrakce u OOP

« kdy: 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ě?

176

Vývoj / Re:Abstrakce u OOP

« kdy: 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?

177

Vývoj / Re:Abstrakce u OOP

« kdy: 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.

178

Vývoj / Re:Abstrakce u OOP

« kdy: 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.

179

Vývoj / Re:Abstrakce u OOP

« kdy: 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?

180

Vývoj / Re:Abstrakce u OOP

« kdy: 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.