Jak se neztratit ve vlastním kódu?

[standa12345]

...Ono když má člověk metodu, co má 1000 řádků, tak je to sice možná prasárna, ale v ifech a forech se člověk nějak dramaticky neztratí, prostě to čte shora dolů a postupně to pochopí....

Baví se 2 programátoři: Franto, ty používáš na kodění netbook? A nemá to nějak příliš malý display?
Franta: Ani né, Pepo. Když se mi totiž metoda nevleze na obrazovku, tak dělám něco špatně.

[Reklama]

[Petr]

Každému vyhovuje něco jiného. Také záleží od jazyka a úlohy.

Takže já třeba preferuji Vim a na Python nebo PHP debugger nepoužívám, na javascript občas ano. Ale obecně dávám přednost logu. V realtime aplikacích imho ani debugger používat nejde, protože chod aplikace nelze pozastavit a krokovat. Ale průběh lze zalogovat a log analyzovat. Stejně tak nelze debugger použít u občasných náhodných chyb. Takže loguji do paměti a když dojde k jednou začas k chybě, log uložím do souboru. Jako všechno, musí se to umět, správné logování. U mě je přirozenou součástí programování, dělám ho automaticky, preventivně, ne až když je nějaký problém. Debugger je pro mě spíše obezlička pro jednoduché případy.

Co se týče otázky, jak se neztratit ve vlestním kódu, tak rada je jednoduchá. Psát kód přehledně. To znamená v první řadě kód dobře rozdělit na části (moduly, třídy, metody, funkce, ...) a tyto dobře pojmenovat. Naplnit tuto radu není jednoduché, chce to praxi a zkušenosti. Pak už mi stačí propracovaná práce s foldingy ve vimu, používám výhradně ruční metodu marker. A nejsem vyznavač krátkých metod/fýnkcí za každou cenu. Zvláště větvící metody je zbytečné rozdělovat, takže ty mohou být dlouhé stovky řádků, pokud větvících eventů je hodně. A obecně se neřídím délkou, ale funkčností. Základ je, že část kódu by měla dělat jednu věc, aby šla dobře poumenovat a že by se kód neměl opakovat. takže mohou vzniknout i jednořádkové metody. Prostě jak je potřeba.

Druhá rada je tvorba kvalitní dokumentace. Nebo aspoň komentářů. V tomto jsou dobrá pomůcka samodokumentující docstringy pythonu.

Ale to všechno je individuální, každému vyhovuje něco jiného. Takže se tím můžeš nechat inspirovat, ale stejně si nakonec musíš najít svou vlastní cestu. Pokud nejdeš do korporátu nebo nepracuješ na velkém formalizovaném projektu, kde ti cestu určí někdo jiný.

[andy]

Ty jo, debugger... tak nějak vzhledem k tomu, že větší část mých projektů je taková, že to pořádně nejde, tak jsem si nějak odvykl. A vůbec mi to nechybí. Při pár příkladech jsem to teda skousnul a to gdb spustil, ale to byla fakt výjimka. Ale vzpomínám na začátky programování, kdy bych se bez debuggeru nepohnul....

Pamatuju, jak hardwarové watchpointy na přepsání paměti byly fakt vychytávka. Za posledních 10 let jsem něco takového nepotřeboval ani jednou. A říkám si, že to možná bude tím, že používám jiné jazyky, používám je jinak a ve výsledku dělám "jiné chyby", resp. ty "staré" chyby jsem schopen diagnostikovat poměrně slušně i bez debuggeru.

Navíc dneska když dojde k nějaké chybě, tak už u toho typicky má člověk třeba traceback, takže se ex-post dozví spoustu věcí a velmi často je schopen problém diagnostikovat aniž by potřeboval přímo něco testovat. Tím neříkám, že debugger je na nic, ale případů, kdy jsem ho opravdu potřeboval, bylo docela málo.

[ghost]

debuger vam userri spoustu casu vy bejci, jak pri vyvoji tak pri hledani chyb

[Kit]

debuger vam userri spoustu casu vy bejci, jak pri vyvoji tak pri hledani chyb

V Assembleru už dávno nedělám.

[Reklama]

[dcfcxx]

debuger vam userri spoustu casu vy bejci, jak pri vyvoji tak pri hledani chyb

Debugovani je jako detektivka, kde vysetrujete zlocin.
A sam jste zaroven i vrahem.

[jablon]

Je to poměrně jednoduché. Musíte psát podle standartu, dodržovat code style. Pokud vás dělá více, pak by nemělo jít poznat, kdo jakou část psal (krom anotace @author).

[gll]

Je to poměrně jednoduché. Musíte psát podle standartu, dodržovat code style. Pokud vás dělá více, pak by nemělo jít poznat, kdo jakou část psal (krom anotace @author).

jaký smysl má používáni @author, když tu stejnou informaci máte ve verzovacím systému?

[JmJ]

Je krasne, jak se vetsin z vas tvari hrozne profesionalne a pritom tvrdi takove veci jako ze debuger je na nic, ze ho nahradi logovani a ze tamhleto je blbost a dokonale a spravne je neco uplne jineho atd.

Ze trida ma mit 6 metod, nebo zase ze metoda muze mit i 1000 radku se zanorovanim a je to ok atd. Kazdy si halt obhajuje tu svoji prasecinu a nejhorsi jeste je, kdyz se na netu od nejakeho jinehou joudy docte to, co se mu hodi do kramu, to pak zacne tuto myslenku vydavat za svetonazor a nuti do toho i ostatni.

Neni nad to, kdyz nejaky blbec zacne programovat podle tehle doporuceni. Pak se program nepis pro to, aby fungoval, ale proto, aby splnil nejaka nesmyslna kriteria na podobu kodu.


Kod ma mit svou fazonu, v ramci projektu idealne jednotnou. Nazvy metod a parametru by mely fungovat ve velke vetsine pripadu jako napoveda a metody by se mely chovat rozumne podle toho, jak se jmenuji a jake parametry zerou.  Kod je vhodne (nikoliv nezbytne nutne) psat tak, aby byl citelny a pochopitelny. Mista, ktera tak napsat nejdou napr. z duvodu optimalizace by mela byt rozumne okomentovana. Naopak psat komentar ke konstruktoru bez parametru, ze je to konstruktor, je nemysl. Ale jsou taci, co to vyzaduji.  Kod by se nemel zbytecne opakovat a to jak z duvodu prehlednosti, tak udrzovatelnosti. Vyjimkou jsou opet napr. optimalizace.

Cele "reseni" ma byt rozdeleno na mensi celky, ktere maji byt si s sebou maji tahat co nejmene zavislosti a maji byt co nejvice znovupouzitelne. Pri tvorbe trid, sluzeb, komponent atd. vzdy hledime na to, jak by danou vec asi chtel znovupouzit uplne cizi programator, resp. si vzpomeneme, co nas stve na cizich komponentach a sami to udelame pokud mozno lepe.

Ve celem "reseni" dodrzujeme jednotny styl nazvu pro ruzne casti, od namespacu po promenne. Dorzet jednotnost u namespacu je rozhodne dulezitejsi, nez ji dodrzet u lokalni promenne v privatni metode tridy pro praci se stringy.

Vcas reseni refaktorizujeme, pokud je to nutne, nikdy (az na uplne krize) nelepime kod jako prasata. Nekdy muze refaktorizace zabrat hodne casu. Je lepsi ji delat vcas, treba po te, co se zhotovi nejake reseni, udela se zakladni test, ze to jede. Nechvastame se, jak sme dobri, ale venujeme cas tomu, abychom tohle reseni ucesali, uklidili kod po prekotnem vyvoji atd.

Za chyby v textu se omlouvam, nechce se mi to po sobe cist ;-)