Abstrakce u OOP

[Kit]

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.

[Reklama]

[Mirek Prýmek]

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.

[tomas88]

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).

[Kit]

... 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.

[Mirek Prýmek]

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.

[Reklama]

[Kit]

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?

[listoper]

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.

[Kit]

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.

[Jiří Havel]

... 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?

[Jiří Havel]

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.

[qelurg]

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í.

[Mirek Prýmek]

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>

[Idris]

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.

[listoper]

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?

[Mirek Prýmek]

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ů.