Přejít k navigační liště

Zdroják » Různé » Jak psát hezký kód II

Jak psát hezký kód II

Články Různé

V minulém díle tohoto miniseriálu jsme se seznámili se základní teorií a prakticky jsme si ukázali, jak vytvářet různé názvy (proměnných, funkcí, tříd atd.) či jaké psát funkce. Dnes, jak jsme si minule v závěru slíbili, si povíme o psaní objektů (tříd), komentářů a o tom, jak vlastně kód formátovat.

Seriál: Hezký kód (3 díly)

  1. Jak psát hezký kód I 13. 4. 2010
  2. Jak psát hezký kód II 20. 4. 2010
  3. Jak psát hezký kód III 27. 4. 2010

Objekty

Objekty není jistě potřeba moc rozepisovat, protože pro ně platí více méně stejné zásady jako pro funkce/metody. Objekty pište malé! Možná se teď divíte, proč psát objekty malé. „Co když bude prostě objekt muset obsahovat víc věcí? Například objekt obsluhující e-shop?“ Nemusí! Proč byste psali jeden objekt, která obsluhuje e-shop, když můžete elegantně napsat více objektů – jeden se stará o přihlašování, jiný zase o katalog, další o nákupní košík, .. Okamžitě potom víme, který kus kódu kde hledat. V jednom objektu bychom těžko hledali, kde je kód obsluhující nákupní košík.

Tím se také dostáváme k tomu, že každá třída, objekt, by měl(a) mít na starost jen jednu věc. Pokud nastane jakákoliv změna v aplikaci, tak důvod, proč jít změnit určitý objekt, by měl být jen jeden. Vezměme například opět e-shop – chceme v této aplikaci změnit způsob listování v katalogu, kam půjdete? Půjdete najít aplikační (chcete-li logický) kód, změníte obsah proměnných a poté půjdete udělat potřebnou úpravu do šablon. Toto je logický postup, který během chvilky provedete, ale záhy zjistíte, že najednou objekt obsluhující nákupní košík hází chyby – jak to? To bude asi tím, že nějaký Franta Moula, který nečetl nic o tom, jak psát kód co nejlépe a hezky, provázal nelogické části. Vyhněte se tomu! Logicky spojujte to, co k sobě patří, a nezavádějte zbytečné propojení. Při rozdělování velkých objektů na menší se nesnažte propojení udržovat – zrušte ho.

Další pravidlo: Zapouzdřujte! Nenechávejte ukazovat světu, jak vaše bezva-cool třída funguje. Ukažte jen to, co je nutné. V minulém díle jsme si ke konci říkali, že při velkém počtu argumentů je dobré tyto argumenty obalit do objektu. Ukazovali jsme si to na příkladu souřadnic bodu. Dnes do ukázky doplníme samotný objekt a ukážeme si špatný a dobrý způsob.

class Point:
    x = 0
    y = 0

    def __init__( self, x=None, y=None ):
        if not x == None:
            self.x = x
        if not y == None:
            self.y = y

class Point:
    __x = 0
    __y = 0

    def __init__( self, x=None, y=None ):
        self.setXY( x, y )

    def setXY( self, x=None, y=None ):
        self.setX( x )
        self.setY( y )

    def setX( self, x=None ):
        if not x == None:
            self.__x = int( x )

    def setX( self, y=None ):
        if not y == None:
            self.__y = int( y )

    def getXY( self ):
        return [ self.__x, self.__y ]

    def getX( self ):
        return self.__x

    def getY( self ):
        return self.__y

V tomto příkladu je jasně vidět, že první způsob je sice rychlejší, ale zato méně bezpečný. V proměnné x nebo y se může vyskytnout klidně i řetězec. Můžeme si s instančními proměnnými dělat doslova co chceme. Naopak v druhém případě svoje proměnné chráníme. (Může ale vzniknout chyba při převádění do integeru – v ukázce není uvedeno zpracování výjimky.) Je možné, že na první pohled nevidíte přínosy tohoto řešení – vždyť se upíšete, a přitom jde jen o hlídání proměnných. Ale co kdybychom chtěli přidat ještě možnost pracovat s polárními souřadnicemi? V prvním případě, kde jsme nezapouzdřovali, bychom museli pracovat s převodem složitě. Všude, kde bychom pracovali s polárními souřadnicemi, bychom museli napsat kód s převodem, a u toho nezapomínat, že můžeme dostat nesprávné hodnoty. Složité, komplikované a porušovalo by se pravidlo DRY (Don’t Repeat Yourself). Při zapouzdřování bychom jednoduše přidali další metody a při využívání objektu bychom se už o nic nestarali.

class Point:
   def __init__( self, x=None, y=None, r=None, angle=None ):
      ...
   def setXY( self, x, y ):
      ...
   def setX( self, x ):
      ...
   def setY( self, y ):
      ...
   def setR( self, r ):
      ...
   def setAngle( self, angle ):
      ...
   def getX( self ):
      ...
   def getY( self ):
      ...
   def getR( self ):
      ...
   def getAngle( self ):
      ...

Všimněte si, že tento objekt nic neříká o tom, jak uvnitř funguje. Nechá nás pracovat pouze s veřejnými metodami, a dává nám možnost pracovat s polárními nebo kartézskými souřadnicemi. A tak to je správně.

Komentáře

Hned na začátek tu mám nemilou zprávu pro kódové spamery: Komentáře nepište! Proč nepsat komentáře? To je jednoduché: 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 tím se stává komentář neplatným a zbytečným. Tomu stěží zabráníte. Já osobně jsem komentáře nikdy neudržoval v dobrém stavu. (Ukamenujte mě za to, že jsem líný programátor, co nemá právo psát něco o hezkém kódu.) – pozn.aut. Vždy se stalo, že komentář přestal být aktuální, že nebyl potřeba. Je zbytečné při vývoji ještě hledět na komentáře, už tak je dost práce s údržbou kódu. Proto je nepište.

Komentáře nepíšeme, protože samotný kód je jeden velký komentář. Kód píšeme tak, aby se dobře četl a nepotřeboval komentáře. Pokud není z kódu patrné, co dělá, tak je určitě způsob, jak ho napsat lépe, čitelněji. Podívejme se na následující kód, co asi dělá?

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

U tohoto kódu stěží uvidíme, co se děje. Někteří by řekli, že by se hodil komentář – ano, určitě tady by byl komentář ideální, ale proč psát komentář, když by šlo kód napsat čitelněji, třeba takto:

lowMultiplication = []
for x in range( 1,11 ):
    line = []
    for y in range( 1,11 ):
        line.append( x*y )
    lowMultiplication.append( line )

Nyní je kód čitelnější. I ti, kteří se nevyznají v Pythonu, dokáží kód přečíst. V kódu je také vidět, jak hodně pomohl lepší název proměnné. Dalším příkladem může být jakákoliv složitější podmínka. V našem e-shopu se může vyskytnou podmínka, kdy se testuje, zda je uživatel přihlášen a má nárok na slevu. Taková podmínka by mohla vypadat například takto:

# podminka, zda je uzivatel prihlasen a zda ma narok na slevu (flag je nastaven na 2)
if user.isLogin() and user.flag == 2:
    ...

Strašlivá podmínka, že ano. A to nesmíme zapomenout, že se kód může kdykoliv změnit. Právo na slevu bude najednou označeno s flagem 3, a pak musíme upravit nejen podmínku, ale i komentář. Nemluvě o tom, že tato podmínka se nemusí vyskytnout jen jednou. Hezké vylepšení by bylo použitím konstanty a tím odstranění konce komentáře. Podmínka ale stále zůstává mohutná a těžkopádná. V takovéto podmínce se mohou vyskytovat chyby – může se stát, že zapomenete na jednom místě přidat kontrolu flagu, a už máte na telefonu majitele e-shopu, co jste to provedl. Hezkým řešením by bylo tuto podmínku vložit do funkce, nebo ještě lépe do metody.

if user.hasDiscount():
    ...

Nyní je jasné, co se děje, aniž bychom potřebovali udržovat komentář nebo se bát, že na některém místě zapomeneme celou podmínku napsat.

Čas od času se ale někde hodí komentář použít. Hodí se to například k regulárnímu výrazu – takový komentář je velmi užitečný, protože řekne mnohem rychleji vše, co by řeklo dlouhé čtení regulárního výrazu. Můžete komentářem vysvětlit, co zamýšlíte a proč to děláte zrovna takto. Já osobně jsem před časem řešil jakýsi problém, a vyřešil jsem jej jedním řádkem kódu (a samozřejmě jsem si k němu nenapsal dobrý komentář, proč jsem to vyřešil zrovna takto). Po čase jsem kód procházel, všiml jsem si toho řádku a zarazil se. Porozhlédl jsem se kolem, a dotyčný řádek jsem nakonec smazal, protože se mi zdál zbytečný. Aplikace poté házela chyby a mně ihned došlo, čím to je – smazaným řádkem, který se zdál zbytečný, a přitom byl velmi důležitý. Napsal jsem k němu komentář, proč tam je, a někde v mých kódech nejspíš žije dodnes.

Čas od času je dobré použít komentář – v opačných případech je to špatně. Podívejte se na následující ukázku. Jsou v ní vidět tři typy špatných komentářů. První komentáře pouze zakrývají hlavičku funkce a neříkají nic nového. Další komentáře u podmínek jsou úplně zbytečné. Přeci vidíme, co se děje – kód vše řekl a komentáře nejsou potřeba. Poslední komentář je naopak chybný, matoucí. Kód vrací při neplatném faktoriálu nulu a v komentáři je napsáno None. Zde se původně asi vracelo None, ale poté byla hodnota upravena na nulu a (zbytečný) komentář se zapomnělo upravit.

# vrati faktorial daneho cisla
# @param cele cislo
# @return faktorial
def factorial( x ):
    if x == 0: # pokud je x rovno 0 vrati 1
        return 1
    if x > 0: # pokud je x vetsi nez 0, tak vynasobi x cislem o jednotku mensi
        return x * faktorial( x-1 )
    else: # jinak vrati 0
        return 0 # neplatny faktorial - vraci se None

Nakonec ještě jedna rada: nezakomentovávejte kusy kódu. Je to zbytečná komplikace. Kód rovnou smažte! Nemusíte se přeci bát, že o něj přijdete – vždyť přeci používáte verzovací systém a kdokoli si kód můžete dohledat. (Nepoužíváte verzovací systém? Chyba! Začněte! Doporučuji používat Git. Je o něm pěkná kniha Pro GIT, kterou si můžete stáhnout v PDF formátu, a i na Zdrojáku vyšel seriál Pět důvodů proč použít Git.)

Závěr

V dnešním dílu jsme si řekli, že:

  • Objekty by měly být malé.
  • Objekt by měl mít na starost jen jednu věc.
  • Nezapomínejte zapouzdřovat.
  • Nepište zbytečné komentáře. Místo komentáře použijte popisnější kód.

Příště se podíváme na formátování kódu.

Komentáře

Subscribe
Upozornit na
guest
30 Komentářů
Nejstarší
Nejnovější Most Voted
Inline Feedbacks
View all comments
xx

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? ;-)

stej

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 .

mishak

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)

xx

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.

LZ

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

zasekomentáře

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

hrp

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

Riny

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.

K.K.

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!

Riny

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.

uf

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.

Riny

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.

uf

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

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

Riny

Asi jo :3

KarelI

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

Michal Augustýn

K funkcionálnímu programování vede už Váš první odstavec – de facto popisujete tzv. immutable typy :)

KarelI

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.

Jan Kodera

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.

Honza Kral

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.

okbob

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.

xx

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?
Lucien Lachance

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…

Michal Augustýn

Jsem první, koho zaskočilo, že autor volně zaměňuje třídy a objekty? :O IMHO je jedním ze základních prostředků porozumnění i používání správné/zavedené terminologie…

Tomáš Herceg

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

alef0

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?

Pavel Dvořák

Haskell nemá cykly, místo toho využívá rekurzi. A když už se ptáš, tak taktéž podporuje generátory seznamů, bylo by to tedy:

foo = [[x * y | x <- [1..10]] | y <- [1..10]]

Pavel Dvořák

A ještě tedy ta druhá verze, za použití dvou mapů a anonymní funkce a operátorového řezu:

foo = map (x -> map (x*) [1..10]) [1..10] 

Zdá se mi to ještě víc nepřehledné než ty dva zanořené cykly.

uf

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.

Aleš Roubíček

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.

uf

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.

Enum a statická analýza kódu

Mám jednu univerzální radu pro začínající programátorty. V učení sice neexistují rychlé zkratky, ovšem tuhle radu můžete snadno začít používat a zrychlit tak tempo učení. Tou tajemnou ingrediencí je statická analýza kódu. Ukážeme si to na příkladu enum.