Zlepšení čitelnosti vlastního kódu

[redustin]

Srovnání s orgány v těle je pěkné a skoro by to i vypadalo, že se rozdělení bloků v softwaru také není žádná věda. Jenže ty orgány mají ještě řídící vrstvu, kde každý nerv vede pěkně samostatně do centrálního kontroléru - mozku. Co jsem si našel, v krční míše je minimálně milión nervů. Plus některé orgány mají vlastní mini kontroléry přímo u sebe (např. srdce) A to už tak pěkné oddělení do bloků není.  Oddělit datové toky, to je většinou snadné, ale vyřešit distribuované řízení, aby navíc bylo rychlé a efektivní (tj. ne message pro každý signál), to bývá největší starost.

Rozdělení do bloků a vytvoření elegantního API je dle mého názoru na programování to nejobtížnější a vyžaduje cit a zkušenosti.

[Reklama]

[anonacct]

Pokud nějaký jedinec dělá chyby opakovaně a řeší se na každém code review - a tady myslím i to, že nedokáže dát na review kód, který by splňoval nějaké firemní guidelines a coding style, tak vidím jen jedno řešení - pá pá.

[Kit]

Trochu si rypnu. Ten if (device.Type == "android")  je stoprocentne pouze na jednom miste v programu :-)

To jsem si vymyslel za chodu, to neni z zadneho programu. Normalne by byl android nejaky enum, ale pro citelnost teto kratke ukazky jsem tam nechal "android" aby jakoze bylo jasne, co se oproti cemu kontroluje.

Taky by se dalo napsat

Kód: [Vybrat]

if (device.IsAndroid) ...

[Kit]

Dále: 80 znaků je archaismus, ale občas to řádky zalomit chce (mluvím k sobě, mám máslo na hlavě, kolega řešící diff nějakého mého kódu mi za to nedávno nedával...)

80 znaků je dobrý softlimit, ještě lepší je 65 znaků. Lépe se to čte.

Zalamování se snažím vyhýbat, raději řádek rozdělím do proměnných, jejichž názvy poslouží jako komentáře a poté je použiji ve výsledném příkazu, který je pak kratší.

Alternativou je důsledné zalomení parametrů volané funkce či metody, aby byly hezky pod sebou, ale tam pak chybí ty komentáře v názvech proměnných.

[Jiří Havel]

Občas na školení používám přirovnání lidského těla k ideální architektůře zdrojového kódu. V lidkém těle také nemáte zaimplementované plíce přes střeva a dolní končetini. Všechno má jasnou funkci, přenos, struktura, data, vstup, výstup apod. A dalo by se říct že je to miliony let laděný systém .

Lidské tělo je ukázkový příklad toho, jak vypadá výsledek milionů let flíkování a hákování

Světlo jde ke světlocitlivým buňkám v oku skrz vrstvu neuronů a místa, kde díky tomu nic nevidíme, doplňuje "firmware". Třeba chobotnice mají oči navržené příčetně.

Nerv k hrtanu nám vede dolů, kolem aorty a pak zase zpátky nahoru

A co za divočiny dělá náš mozek proto, abychom si nevšimli, že při změně směru pohledu chvíli nic nevidíme by vydalo na knihu.

[Reklama]

[Pixe]

Tohle především nemají řešit lidi, ale stroje a nástroje (eslint, checkstyle,...) - ideálně nastavené napříč organizací. Jejich (opodstatněné) porušení pak řešit anotací/při code review.

Počet znaků je pak přímo úměrný velikosti monitorů které vyfasujete

Dále: 80 znaků je archaismus, ale občas to řádky zalomit chce (mluvím k sobě, mám máslo na hlavě, kolega řešící diff nějakého mého kódu mi za to nedávno nedával...)

80 znaků je dobrý softlimit, ještě lepší je 65 znaků. Lépe se to čte.

Zalamování se snažím vyhýbat, raději řádek rozdělím do proměnných, jejichž názvy poslouží jako komentáře a poté je použiji ve výsledném příkazu, který je pak kratší.

Alternativou je důsledné zalomení parametrů volané funkce či metody, aby byly hezky pod sebou, ale tam pak chybí ty komentáře v názvech proměnných.

[JurajP]

Oplati sa citat knizky od Fawlera?

[luvar]

Dobry den,
ospravedlnujem sa za nasledovne, ale imho:
Predosle komentare su irelvantne!

Otázka bola, ako písať lepší kód s cieľom, aby kolegovia nespomínali trpazlíkov a anláne otvory... K tomuto je imho jediná cesta. Získať od nadriadeného súhlas s 40 clovekohodinami na mesiac. 20 hodín od pýtajúceho sa a 20 hodín od autora výroku s trpazlíkom. Následne riešiť párové programovanie a diskutovať pri tom na úrovni. Stručné zásady, ktoré si spomínam zhlavy:

• rozumný čas na session (hodinka, max dve asi)
• ak je rôzny level skilu (asi je), tak to vyvážiť rovnakým levelom skilu ohladne biznis domény problému, ktorý sa rieši
• na začiatok určite pár sedení s implementáciou nových vecí (nie refaktoring)
• určite dodržiavať striedania (ten, čo nemá klávesnicu stráži mená premenných a čas a interrupt robí ideálne po nejakých celkoch)
• skúsiť si veci vysvetlovať a pýtať sa, ale nezachádzať moc "offtopic"

PS: S mensou efektivitou je mozne dosiahnut ciastocne rovnaky efekt aj cez code review.
PS2: Je nutné, aby aspoň trochu chcenia bolo aj na druhej strane a aby bol cielom kúsok lepší kód, ako keby ho písal len jeden človek...
PS3: Ak sa rozhodnete pre tento smer, odporúčam venovať cca 1MD naštudovaniu, ako robiť párové programovanie... Ak by to malo byť na viac ako mesiac, tak tomu kludne po mesiaci obetovať aj viac času...

[Kit]

Tohle především nemají řešit lidi, ale stroje a nástroje (eslint, checkstyle,...) - ideálně nastavené napříč organizací. Jejich (opodstatněné) porušení pak řešit anotací/při code review.

Počet znaků je pak přímo úměrný velikosti monitorů které vyfasujete

Stroj (zatím) nedovede smysluplně pojmenovat proměnnou nebo funkci, která by vznikla rozpadem dlouhého příkazu na větší množství krátkých.

Na velikosti monitoru by vůbec nemělo záležet. Co když si to pak chci číst na tabletu nebo na mobilu?

[PanVP]

To mi přijde jako velmi rozumný nápad.
Totiž, codereview se nedělá "v grupě", ale jen s vedoucím daného projektu a na refaktorizaci obvykle není ...čas/chuť/zákazník to nechce zaplatit/...

[Jiří Havel]

Na velikosti monitoru by vůbec nemělo záležet. Co když si to pak chci číst na tabletu nebo na mobilu?

Co by mělo a nemělo je celkem jedno. Záleží nejen na velikosti ale i na dalších aspektech ovládání. I jeden velký monitor je dost bída. Číst kód na mobilu je těžká nouzovka, pro kterou nemá smysl optimalizovat formátování a tím házet vidle do běžného použití.

Pro takovéhle "divné" situace si to můžete prohnat nějakým automatickým formátovačem.

[listoper]

Na velikosti monitoru by vůbec nemělo záležet. Co když si to pak chci číst na tabletu nebo na mobilu?

Co by mělo a nemělo je celkem jedno. Záleží nejen na velikosti ale i na dalších aspektech ovládání. I jeden velký monitor je dost bída. Číst kód na mobilu je těžká nouzovka, pro kterou nemá smysl optimalizovat formátování a tím házet vidle do běžného použití.

Pro takovéhle "divné" situace si to můžete prohnat nějakým automatickým formátovačem.

Na mobilu sem delal code review jednou... bez toho se obejdu. Ale co treba takovy 3-way diff treba pri merge conflictu?
To mam kazdou chvliku a hrozne me rozciluje kdyz kvuli tomu musim horizontalne scrollovat.
Vetsinou se vejdu do 80 znaku bez premysleni a jsem za to rad.

[Idris]

Literate programming od Knutha obsahuje zajímavé myšlenky.

[Pixe]

To ale nikde netvrdím - série příspěvků na kterou jsem reagoval byla o počtu znaků, zalamování, zarovnávání... Ostatně to samé platí i pro úvodní příspěvek a v něm odkazované naming-conventions, které za vývojáře taky ohlídá počítač.

Stroj (zatím) nedovede smysluplně pojmenovat proměnnou nebo funkci, která by vznikla rozpadem dlouhého příkazu na větší množství krátkých.

...

[Jiří Havel]

Na velikosti monitoru by vůbec nemělo záležet. Co když si to pak chci číst na tabletu nebo na mobilu?

Co by mělo a nemělo je celkem jedno. Záleží nejen na velikosti ale i na dalších aspektech ovládání. I jeden velký monitor je dost bída. Číst kód na mobilu je těžká nouzovka, pro kterou nemá smysl optimalizovat formátování a tím házet vidle do běžného použití.

Pro takovéhle "divné" situace si to můžete prohnat nějakým automatickým formátovačem.

Na mobilu sem delal code review jednou... bez toho se obejdu. Ale co treba takovy 3-way diff treba pri merge conflictu?
To mam kazdou chvliku a hrozne me rozciluje kdyz kvuli tomu musim horizontalne scrollovat.
Vetsinou se vejdu do 80 znaku bez premysleni a jsem za to rad.

Tak využít celou šířku monitoru není dobrý nápad nejen kvůli diffům Pokud je takových dlouhých řádků nějak moc, tak to smrdí.
Já řešil čistě tu myšlenku, že bych měl u formátování kódu řešit jak to bude vypadat na mobilu nebo tabletu.