Názory k článku
Jak psát hezký kód II

Nemohu si pomoct, ale toto

foo =  [ [ x*y for y in range( 1,11 ) ] for x in range( 1,11  ) ]

je mnohem přehlednější, než to opravené.

Usuzuji správně, že autor není fanouškem tzv. point-free style? ;-)

Souhlas. Opakující se vzor je často lepší nechat co nejkratší než ho rozepisovat do větších bloků. Tím vzorem teď mám na mysli co for neco in range .

Mohl by jste napsat proč je přehlednější?

Autorovou silnou inspirací je knížka školy psaní kódu (ve smyslu stylu kódu), její instrukce by měly být chápány jako pravidla a pokud možno vždy dodržovány. Napsat z ní výtah je zjevně možné, ale bez upozornění, že jde o systém pravidel a ne doporučení, tu budou častější komentáře typu: je nebudu používat, protože s nimi nesouhlasím. (za prognostiku se omlouvám)

Mohl by jste napsat proč je přehlednější?

Protože je deklarativní, je to přímo definice. V tomto případě je navíc na první pohled vidět, co je výsledek, takže tu není žádný důvod to přepisovat (snad jen foo přejmenovat na  multiplicationTable).

tu budou častější komentáře typu: je nebudu používat, protože s nimi nesouhlasím

Člověk s tím nesouhlasí z nějakého důvodu. Například proč psát gettery/settery v Pythonu, když je nepotřebuje.

Mi připadá upravený kód mnohem přehlednější, v tomhle jsou jen závorky a pár slov.
Chapu, že minimalizace je super, ale jen když napíšete kód, otestujete a když funguje, tak na nej zapomenete.

Ale celkově tenhle článek nějak za moc nestojí. V minulém bylo použivejte max 2 parmetry a buch hned sou v init 4.

Rovněž "nepouživejte komentáře" se dost podobá pravidlu "pište javadoc", rozdíl je akorát v tom, že si pravidla navzájem odporují.

„Když vyvíjíte aplikaci a píšete do kódu komentáře, tak často zapomenete při změně komentář patřičně upravit,“
… a sám si pak okomentoval, že je línej. Stalo se mi asi všehovšudy jednou, že jsem zároveň s kódem zapomněl upravit i (krátký a stručný zdůvodňující – proč třeba tak a ne jinak) komentář. A navíc i v tom případě z něj bylo zcela jasný a mnohem rychlejší vyčíst než přímo z kódu kde jsem, co to dělá, a proč to dělá.

… a následně autor přidává opravdu zbytečné a zbytečně podrobné komentáře, přitom o tom se s ním taky nikdo nikdy nepřel.

Ale je to samozřejmě každýho věc, já komentáře píšu, ale vůbec ne tak nesmyslně a hustě jako autor, a úpravy kódu jsou pak mnohem rychlejší, i kdyby to právě z kódu bylo po chvilce jasný.

Každej svýho štěstí strůjcem. Každýmu co jeho jest. Ale zakazovat komentáře je prostě pitomost a je to zrovna jedna z věcí, kterou si stejně každej bude a nebo nebude dělat jak chce.
Pak je jiná věc práce na kódu v týmu, ale tam jsou krátké zdůvodňující komentáře potřeba ještě o to víc, takže fakt nechápu… OK, asi jsem natvrdlej.

Já bych ještě dodal, že ukazovat zbytečnost dokumentačních komentářů na funkci faktorial je přinejmenším úsměvná. Prostě dokud se člověk nespálí, tak neuvěří.

Jn, plně souhlasím. Spíš by se to pravidlo mělo změnit na psát komentáře s rozumnou mírou a tam, kde je to potřeba. V podstatě bych to přirovnal, jak nás učitel minulý semestr upozorňoval na „paralýzu analýzou“ – při psaní dokumentace k informačnímu systému vážně není potřeba detailně popisovat (a nejlépe ještě kreslit DFD) procesy, jako je jednoduchý insert dat do databáze.

Ale jinak je článek fajn, takové věci by se měly učit ve škole. Sice nás třeba nutí psát gety a sety k proměnným, ale na nějaké zapouzdřování nepřijde řeč, takže to může působit spíš jako zbytečná buzerace.

To se Vám to píše, jak co psát, když programujete (asi jako ve škole) jen matematicky jasné algoritmy.
Ale většina skutečných programů využívá algoritmy. které nejsou jednoznačně dané, obsahují řadu výjimek a hlavně, ty se během života programu mění. Jestli tohle někdo zvládne bez komentářů, tak to ani sám po sobě není schopen časem zaktualizovat. A když ještě nejde nebo nesmí používat v programu GOTO, tak se v podmínkách po třetí aktualizaci už sám nevyzná ani s komentáři.
Na funkční a léta pracující programy je totiž jediné pravidlo. Nikdy jejich kód neukazovat počítačovým teoretikům!

Asi došlo k nějakému nedorozumění, protože já se snažil obhajovat komentáře. Chtěl jsem říct, že je považuji za důležité (tudíž v tomto nesouhlasím s článkem), ale zároveň jsem chtěl říct, že se to s nimi nemá přehánět (a komentovat každou jednoduchou podmínku a proměnnou. Např. k proměnné „sum“ je asi nesmysl psát „celkový součet“.)
Ke goto se nevyjadřuji – vím, že se kolem toho vedou „náboženské války“ a názor si hodlám utvořit až praxí (a prozatím jsem nedělal nic, kde bych jej potřeboval).
A jak je psáno v Code Complete (Dokonalý kód) – všechny konvence musí mít smysl a nesmí se na nich nesmyslně lpět, pokud se najde dostatečný důvod, proč je v nějakém případě nedodržet :3.

Ke GOTO: A co jineho je prikaz continue a break uvnitr cyklu nebo predcasny return z metody/procedury? Ve strukturogramu to narusovalo system, ale byla to povolena optimalizace se zvlastni znackou a napisem QUIT.

Strojak s goto pracuje. Archaicky Basic taky. Jinak se nedal udelat cykl nebo if else. Slo o to, aby to bylo rozumne – napr. nakreslitelne jako diagram.

Hezká pointa. I když v případě continue, break a return mi to přeci jen přijde trochu průhlednější (názor laika :3).

Nicméně jak poznamenal kolega výše – zatím nepracuji s doopravdy složitými systémy, takže se držím rad knih: goto nepoužívat, dokud není jiné řešení (nebo je zbytečně složité).

Nicméně souhlasím, koneckonců všechno musí být rozumné – jinak i bez použití výše zmíněných příkazů je práce na nic.

Přiznejte, že je to optimalizace. Jinak by tam byl flag.

Já jsem potřeboval GOTO jen v TSQL a v assembleru

Asi jo :3

Ja obcas rostu, kdyz nekdo bezmyslenkovite automaticky pise settery a gettery. Naopak mam velmi dobrou zkusenost s tridami, ktere jsou zcela nebo temer konstantni. Vse potrebne se preda konstruktorem, pripadne se v nem dopocitaji nejake dalsi veci a pak uz se objekt nemeni. Get je jen tam, kde je nutny. Kod je pak strucny, mnohem mene nachylny k chybam, lehce se hlida konzistence, s instancemi muze pracovat vice threadu bez zamykani, atd.

Kdyz uz je nutna nejaka zmena, tak se snazim povolit tu nejmensi moznou. Napada me treba priklad, kdy si entita v simulaci pamatuje svuj vek. Misto setAge(int) napisu incAge() { age++; }, ktera uzivateli nepovoli delat si co chce. V prvnim pripade by pak uzivatel musel psat setAge(getAge()+1) a logika by vylezala z tridy ven. Casto to tak v realu bohuzel konci.
Ted me napada, ze jeste lepsi by bylo pamatovat si vek narozeni a napsat jen getAge(int time). To uz smeruje k funkcionalnimu programovani, asi tam nekde bude ten ideal :-)

Jo jasne, ja jsem tim hodne ovlivnen a dost veci se mi na tom libi, ale rizenim osudu tak pisu v c++ a jave. Takze si pak nepamatuju, jak se tomu rikava.

Když nechcete udržovat komentáře, programujte za pomocí test-driven development. Test pak bude sloužit jako komentář. Pokud se vám tohle zdá složité, neprogramujte vů­bec.

kdyby mi kdokoliv odevzdal ukazky kodu ke code review, bez zavahani bych mu je vratil – naprosto nerespektuji zasady jazyka ve kterem byly napsany, zbytecne se vyhybaji efektivnim konstrukcim ktere lze vysvetlit pulradkovym komentarem (komentare jsou dobre, a kdyz budou dobre a strucne, lidi je i budou updatovat) a jamile uvidim nekde v pythonu kod ktery obsahuje gettery a settery, zacinam proste silet – jde to zcela proti filosofii toho jazyka i veskerych nastroju kolem toho.

Kdyz uz potrebuju mit tridu bod ktera umi i polarni souradnice (mimochodem i knihovna python-imaging pocita s bodem jako s dvojici cisel (x, y) a z dobrych duvodu), udelal bych x a y normalne public atributy a r a uhel jako property ktere by se v pozadi prepocitavali.

Stejne jako v minulem dilu autor stale nepise podle standardu daneho jazyka, jak tech formalnich (pep-8) tak tech neformalnich.

Podivejte se nekdy na nejaky uspesny open source projekt (rails, django, python) a uvidite komentare v kodu. Idea ze by nekdo kvuli tomu aby se vyhnul psat komentare proto, ze je nebude updatovat, mel psat radove mene efektivni kod ktery nepouziva vyhody daneho jazyka, je zcela zcestna.

Narozdil od minuleho clanku v tomto uz nejsou ani uzitecne rady, naopak jen bludy a myty ktere jsou nebezpecne a uprimne doufam ze nikdy nebudu v teamu s programatorem ktery se temito radami ridi – snad jen krome prvni rady aby objekty byly male.

To, že je autor neschopný, v tom, že si nedokáže udržet konzistenci mezi komentáři a vlastním kódem, netřeba troubit do světa. Hůř, ještě doporučovat takový nesmysl ostatním. Perl, Python, PHP nejsou assembler, skutečně není nutné komentovat každý řádek, každou instrukci – není nutné komentovat, co to dělá. Co je podstatné komentovat – proč a k čemu je komentovaný kód.

Ta ukázka s bodem je dost podivná, jak už mnozí přede mnou poznamenali. Já v Pythonu nepíšu, ale přesto si dovolím pár poznámek:

• Podívejte se, jak se píšou gettery a settery v Pythonu, vy to píšete jak v Javě.
• Proč souřadnice bodu omezujete na celá čísla, co když bude uživatel chtít souřadnice třeba typu float, napíšete pak druhou třídu PointF?
• Proč getXY vrací seznam a ne dvojici?

Komentare musi sednout, samozrejme je blbost psat

// this will load security
$security->load();

Ale jak psal nekdo nize, kod je dobre dlouhodobe funkcni nez se nad nej podivaji teoretici.

A nejhorsi je kdyz se v kodu vrtaji lidi ‚by the book‘, erou podle knizky si musi asi projit kazdy, ale po case mi prijde, ze vetsina knih jak napsat super aplikaci a podobne ma asi stejny efekt jako knizka typu jak uspesne vest firmu z kaufu za sedm petek…

Přesně tak, už první věta „objekty pište malé“ mě dostala. Přestože autor pravděpodobně ví, jaký je mezi nimi rozdíl, není dobré takto mystifikovat ostatní.

Podľa mňa konštrukcia s list comprehension je na hrane, ale to len preto, že neberie do úvahy znalosti vývojára.

Samozrejme, že keď som javista, tak tomu na prvýkrát nerozumiem a for-cyklus je pre mňa prehľadnejší. Ale keď som dlhoročný pythonista, tak mi to príde oveľa krajšie, kratšie a elegantnejšie.

Keby boli ukážky kódu v Haskelli, ako by to vyzeralo? Prepísalo by sa všetko na for-cykly?

Komentare jsou potreba a jsou soucasti kodu. Kdyz upravujete kod, patri k tomu i komentar. Kdyz se na nej vykaslete (vsimnete si, ze nepisu zapomenete), tak se to na funkci programu neprojevi. Vlastne projevi. Pri dalsich zmenach uz to bude zavadejici.

Pred blok piseme dost prehledny a strukturovany komentar problemove domeny tam, kde je to potreba. Za pul roku staci precist komentar a vite, jak se vec zpracovava (z vnejsiho hlediska). Nektere komentare jsme doplnili pri zmenach, protoze jsme tapali, proc to tak je. Urcite nebudu psat u metody getPolomer() komentar „vrati polomer“.

Ke strukturovanosti kodu: Druhy rozepsany zapis je opravdu hezci a prehlednejsi. Jak se treba budete tvarit na text

nejakykod
if (kontrolaDat() && nejakaAkce() && dotaz() && zapis() && akcePoZapisu()) …
kod uvnitr ifu fdsafsd
 afdsfs

jeste lepe zapsano bez mezer?
Jak rychle najdete v kodu, kde se provadi zapis? Vyhledanim? CO kdyz kolega chtel byt moderni a psal persist()?

Krome rozepsani na jednotlive radky jsem videl i predani navratove hodnoty do promenne a jeji testovani.

Jak tak koukám na komentáře, většina lidí tu brání používání komentářů. Samozřejmě v kontextu, který uvádíte máte pravdu. Špatný kód je třeba dobře okomentovat. Nekteří potřebují komentáře a GOTO, aby obešli vlastní neschopnost udělat kvalitní abstrakci nad danným problémem. Ano v takovém stavu jsou komentáře nutné.

Autor ale čerpá z knihy, kde se problematika vývoje bere komplexně. Autor této knihy pracuje stylem TDD, používá popisné názvy metod a proměnných. A nepíše komentáře, prože jich není potřeba.

Komentar (pokud je potreba) je soucasti dokumentace a kodu a mel by se opravovat s kodem. Neopravit komentar je jen vymluva, ze to udelam pozdeji.

Opravite napr. komentar v javadoc pred metodou, pokud dojde ke zmene nebo zpresneni? Asi ano.