Dvě podmínky ve while

[Kit]

Viděl jsi už někdy zdrojáky nějakého většího projektu? Asi ne, závorky nepíše prakticky nikdo. Když jsme na tom portálu o linuxu, podívej se na zdrojáky kernelu, závorky v podmínkách tam nejsou.

Tohle vůbec nelze zobecňovat, protože co projekt, to jiný code styling. Konkrétně u větších projektů závorky vyžaduji. Naopak tam nesmí být prázdné řádky v metodách (to je také šílený zlozvyk) a proměnné musí být příznačně pojmenovány - zkratky se netrpí.

Zdrojáky linuxového kernelu bych rozhodně jako vzor kvalitního stylování kódu nedával.

[Reklama]

[JmJ]

Závorky se píší tehdy když výraz obsahuje více než jednu operaci a to v jakémkoliv jazyce na zeměkouli a má to tuto přidanou hodnotu:
1) Ví se jak to autor programu myslel
2) Složitější výrazy je prakticky nemožné udržet bez závorek bez chyby
3) Ví se rovnou bez hledání v nějakém manuálu jak se to bude vyhodnocovat

Viděl jsi už někdy zdrojáky nějakého většího projektu? Asi ne, závorky nepíše prakticky nikdo. Když jsme na tom portálu o linuxu, podívej se na zdrojáky kernelu, závorky v podmínkách tam nejsou.

Ano zavorky tam casto nejsou, takze se v tom blbe orientuje a blbe se mi ty podminky ctou. Ono vubec je v ovladacich/kernelu dost zajimavych veci ve zpusobu psani kodu, za ktere bych ja svym kolegum urval usi. Kernel neni svaty.

S argumentaci, ze nejaky zpusob psani kodu je zbytecny, protoze se prece z nejakeho okolniho kontextu ci pri blizsi analyze da poznat, co mel autor na mysli, jsem se uz casto setkal a mam k tomu jedine - neni cas ztracet cas.

[Snow]

Komentáře jsou pro pozdější editaci programu řekněme nutnost, platí i v případech kdy za rok po sobě potřebuješ něco předělat, závorky nikoliv. Ale jak píši je to o každém člověku, stejně tak jako někdo používá tabulátor, někdo mezery, nemá smysl rozebírat. Z mého pohledu to zbytečnost je, z tvého ne.

Pokud nepotřebuješ zbytečné závorky, nepotřebuješ ani zbytečné komentáře.

Velkým problémem komentářů je, že když opravíš program, musíš opravit i komentáře. Je to dvojí (a vcelku zbytečná) práce. Drtivá většina komentářů je totálně k ničemu. Komentáře pouze označují místa, kde programátor udělal chybu nebo ještě něco nedodělal.

No ono co je jasné tobě nemusí bejt hned jasné někomu kdo po tobě bude kód opravovat/upravovat proto je rozhodně lepší víc komentářů než míň...
Co se týče závorek tak kdo daný jazyk ovládá jasně ví jak se co vyhodnocuje, když ne neměl by nic upravovat... Ale opakuji jestli se to někomu dobře čte, proč ne, je to jeho věc, stejně tak jako tabulátor x mezera.

[PJ]

nesmí být prázdné řádky v metodách (to je také šílený zlozvyk)

Co je na tom zlozvyk?

U mna je kazda verejna funkcia zlozena z viac casti - minimalne na zaciatku guards a potom bud zavolanie privatnej verzie alebo priamo tam nieco robim. Tieto casti su oddelene prazdnym riadkom.

Je mozne, ze ma funkcia viac casti - ked je viac podproblemov na 2-4 riadky bez konceptualnej zlozitosti a ked sa to bude robit iba na tom jedinom mieste, tak to nevyclenujem do dalsej funkcie, ale kazdy podproblem oddelim prazdnymi riadkami. Ked sa potom zisti, ze niektory podproblem sa ma riesit zlozitejsie, tak nemusim citat nic viac - proste zoberiem usek oddeleny prazdnymi riadkami a vyclenim ho do funkcie.

Komentare su casto zbytocne (casto je to znamka bud duplikacie kodu alebo to znamena hnusny kod), ale ked uz ich pouzijem, tak pred komentar davam prazdny riadok, aby bolo jasne, k comu to patri.

Zdrojáky linuxového kernelu bych rozhodně jako vzor kvalitního stylování kódu nedával.

Hlavne linux kernel nema jeden styl. Je snaha to zjednotit, ale pri politicky pretlacenom kode to nefunguje.

[Kit]

No ono co je jasné tobě nemusí bejt hned jasné někomu kdo po tobě bude kód opravovat/upravovat proto je rozhodně lepší víc komentářů než míň...
Co se týče závorek tak kdo daný jazyk ovládá jasně ví jak se co vyhodnocuje, když ne neměl by nic upravovat... Ale opakuji jestli se to někomu dobře čte, proč ne, je to jeho věc, stejně tak jako tabulátor x mezera.

Komentářů by mělo být co nejméně, aby nezhoršovaly čitelnost programu. Už jsem viděl program, který měl jeden řádek kódu, tři řádky komentáře a navíc jeden řádek prázdný. To se prostě nedalo číst, dokud jsem všechny komentáře a prázdné řádky nevyházel.

O tabulátory vs. mezery se mi kompletně stará editor, nevšímám si toho. A dělá to dobře. A ještě lépe mi funguje clean/smudge v Gitu, který tomu zdrojáku dodá štábní kulturu - klidně pro každý projekt jinak. Umí i přidávat/odstraňovat nadbytečné závorky.

[Reklama]

[Kit]

nesmí být prázdné řádky v metodách (to je také šílený zlozvyk)

Co je na tom zlozvyk?

U mna je kazda verejna funkcia zlozena z viac casti - minimalne na zaciatku guards a potom bud zavolanie privatnej verzie alebo priamo tam nieco robim. Tieto casti su oddelene prazdnym riadkom.

Uvnitř metody nemají prázdné řádky co pohledávat. Bloky jsou dostatečně opticky označené odsazením zanoření. V C-like jazycích koncová "}" je opticky skoro jako prázný řádek, daší je už zcela zbytečný. U Pythonu se prostě vrátí odsazení. Pokud máš někde potřebu vložit prázdný řádek, tak to znamená, že ta metoda má být v tom místě rozdělena.

Každý z guards bývá na 3 řádky - a velmi výrazné řádky. Když mám 3 guards za sebou, tak je opticky naprosto zřetelné, že tam jsou 3 guards. I bez prázdných řádek.

Privátní část je pak dalších cca 5 řádek. Proč bych ji měl oddělovat, když už opticky oddělena je?

Je mozne, ze ma funkcia viac casti - ked je viac podproblemov na 2-4 riadky bez konceptualnej zlozitosti a ked sa to bude robit iba na tom jedinom mieste, tak to nevyclenujem do dalsej funkcie, ale kazdy podproblem oddelim prazdnymi riadkami. Ked sa potom zisti, ze niektory podproblem sa ma riesit zlozitejsie, tak nemusim citat nic viac - proste zoberiem usek oddeleny prazdnymi riadkami a vyclenim ho do funkcie.

Jak se pak vejdeš do 20 řádek/metodu?

Komentare su casto zbytocne (casto je to znamka bud duplikacie kodu alebo to znamena hnusny kod), ale ked uz ich pouzijem, tak pred komentar davam prazdny riadok, aby bolo jasne, k comu to patri.

Aha, takže další zbytečný prázdný řádek.

[gamer]

Je vám všem jasné, že řešíte úplné nesmysly? Nikdy se neshodnete, jestli mají být v podmínce závorky nebo ne, nebo kolik prázných řádků má mít funkce. 100 lidí 100 chutí. Každý je na něco zvyklý a takový kód se mu čte nejlíp, na jíný styl se musí chvíli adaptovat.

[Snow]

Je vám všem jasné, že řešíte úplné nesmysly? Nikdy se neshodnete, jestli mají být v podmínce závorky nebo ne, nebo kolik prázných řádků má mít funkce. 100 lidí 100 chutí. Každý je na něco zvyklý a takový kód se mu čte nejlíp, na jíný styl se musí chvíli adaptovat.

Tak nějak, nemá smysl řešit, což tady už poněkolikáté opakuji...

[Kit]

... 100 lidí 100 chutí...

-- dr. Hannibal Lecter

[PJ]

nesmí být prázdné řádky v metodách (to je také šílený zlozvyk)

Co je na tom zlozvyk?

U mna je kazda verejna funkcia zlozena z viac casti - minimalne na zaciatku guards a potom bud zavolanie privatnej verzie alebo priamo tam nieco robim. Tieto casti su oddelene prazdnym riadkom.

Uvnitř metody nemají prázdné řádky co pohledávat. Bloky jsou dostatečně opticky označené odsazením zanoření. V C-like jazycích koncová "}" je opticky skoro jako prázný řádek, daší je už zcela zbytečný. U Pythonu se prostě vrátí odsazení. Pokud máš někde potřebu vložit prázdný řádek, tak to znamená, že ta metoda má být v tom místě rozdělena.

Každý z guards bývá na 3 řádky - a velmi výrazné řádky. Když mám 3 guards za sebou, tak je opticky naprosto zřetelné, že tam jsou 3 guards. I bez prázdných řádek.
Privátní část je pak dalších cca 5 řádek. Proč bych ji měl oddělovat, když už opticky oddělena je?

A co ked je tam potom nieco dalsie na 3 riadky? Co ked je tam mozno nejaky if? Mne sa to zda byt bez extra riadku dost na hromade.

Je mozne, ze ma funkcia viac casti - ked je viac podproblemov na 2-4 riadky bez konceptualnej zlozitosti a ked sa to bude robit iba na tom jedinom mieste, tak to nevyclenujem do dalsej funkcie, ale kazdy podproblem oddelim prazdnymi riadkami. Ked sa potom zisti, ze niektory podproblem sa ma riesit zlozitejsie, tak nemusim citat nic viac - proste zoberiem usek oddeleny prazdnymi riadkami a vyclenim ho do funkcie.

Jak se pak vejdeš do 20 řádek/metodu?

Ked je tam 1 guard, volny riadok, tak to mam este aj podla tvojho zadania 16 riadkov (ja mam limit o trochu vyssi, takze je to viac). Pri 2 riadkoch niecoho trivialneho + 1 volnom riadku mam miesto asi tak na 5 takychto jednoduchych kuskov kodu, co uz aj pri jednoduchych operaciach znamena spolu nieco netrivialne, co je dobre pomenovat -> spravim funkciu.

Na druhu stranu mat niekde 16 riadkov kodu bez nejakeho oddelenia, to uz znie tak, ze by to nebola "rozpravka na dobru noc".

Komentare su casto zbytocne (casto je to znamka bud duplikacie kodu alebo to znamena hnusny kod), ale ked uz ich pouzijem, tak pred komentar davam prazdny riadok, aby bolo jasne, k comu to patri.

Aha, takže další zbytečný prázdný řádek.
[/quote]

Kód: [Vybrat]

[...]
uint32_t a = ...
[...]

// manual XYZ, p. 455 "highest bit must be set to 0"
a &= 0x7fffffff;

Ked je viac ako ~5 riadkov pokope bez volneho miesta, tak sa v tom stracam a preskakujem riadky.

[Kit]

Uvnitř metody nemají prázdné řádky co pohledávat. Bloky jsou dostatečně opticky označené odsazením zanoření. V C-like jazycích koncová "}" je opticky skoro jako prázný řádek, daší je už zcela zbytečný. U Pythonu se prostě vrátí odsazení. Pokud máš někde potřebu vložit prázdný řádek, tak to znamená, že ta metoda má být v tom místě rozdělena.

Každý z guards bývá na 3 řádky - a velmi výrazné řádky. Když mám 3 guards za sebou, tak je opticky naprosto zřetelné, že tam jsou 3 guards. I bez prázdných řádek.
Privátní část je pak dalších cca 5 řádek. Proč bych ji měl oddělovat, když už opticky oddělena je?

A co ked je tam potom nieco dalsie na 3 riadky? Co ked je tam mozno nejaky if? Mne sa to zda byt bez extra riadku dost na hromade.

Tak tam bude 8 řádek. Bloky "if" nebo "while" budou odsazeny, to je krásně vidět. Víc než 4 úrovně zanoření se stejně nedělají.

Jak se pak vejdeš do 20 řádek/metodu?

Ked je tam 1 guard, volny riadok, tak to mam este aj podla tvojho zadania 16 riadkov (ja mam limit o trochu vyssi, takze je to viac). Pri 2 riadkoch niecoho trivialneho + 1 volnom riadku mam miesto asi tak na 5 takychto jednoduchych kuskov kodu, co uz aj pri jednoduchych operaciach znamena spolu nieco netrivialne, co je dobre pomenovat -> spravim funkciu.

Na druhu stranu mat niekde 16 riadkov kodu bez nejakeho oddelenia, to uz znie tak, ze by to nebola "rozpravka na dobru noc".

Většinou mívám metody i kratší. Mám na obrazovce jen 40 řádek, 3 metody se mi do toho snadno vejdou. Často i celá třída.

Komentare su casto zbytocne (casto je to znamka bud duplikacie kodu alebo to znamena hnusny kod), ale ked uz ich pouzijem, tak pred komentar davam prazdny riadok, aby bolo jasne, k comu to patri.

Aha, takže další zbytečný prázdný řádek.

To nebyl můj koment. Zbytečné řádky nedělám.

[k]

Uvnitř metody nemají prázdné řádky co pohledávat.

Jak se pak vejdeš do 20 řádek/metodu?

Víc než 4 úrovně zanoření se stejně nedělají.

Mám na obrazovce jen 40 řádek

Výkřiky takhle to dělám já a proto je to takhle optimální sem není třeba psát (zrovna všechny čtyři jsou nepravdivé). Zkus podat nějaký důkaz nebo hlubokou myšlenku, jak jsi k tomu došel.

[Kit]

Výkřiky takhle to dělám já a proto je to takhle optimální sem není třeba psát (zrovna všechny čtyři jsou nepravdivé). Zkus podat nějaký důkaz nebo hlubokou myšlenku, jak jsi k tomu došel.

Robert C. Martin: Clean Code

[k]

Takové žvásty fakt číst nebudu, cituji ze strany 34, ale dalo mi to poznání odkud se takové svinstva berou:

In the eighties we used to say that a function should be no bigger than a screen-full.
Of course we said that at a time when VT100 screens were 24 lines by 80 columns, and
our editors used 4 lines for administrative purposes. Nowadays with a cranked-down font
and a nice big monitor, you can fit 150 characters on a line and a 100 lines or more on a
screen. Lines should not be 150 characters long. Functions should not be 100 lines long.
Functions should hardly ever be 20 lines long.

[Kit]

Takové žvásty fakt číst nebudu, cituji ze strany 34, ale dalo mi to poznání odkud se takové svinstva berou:

In the eighties we used to say that a function should be no bigger than a screen-full.
Of course we said that at a time when VT100 screens were 24 lines by 80 columns, and
our editors used 4 lines for administrative purposes. Nowadays with a cranked-down font
and a nice big monitor, you can fit 150 characters on a line and a 100 lines or more on a
screen. Lines should not be 150 characters long. Functions should not be 100 lines long.
Functions should hardly ever be 20 lines long.

No vida, našel jsi to!

I moderní IDE na tebe bude řvát, když překročíš 20 řádek/metodu. Chceš tedy tvrdit, že moderní IDE se řídí podle žvástů?

Pro své potřeby jsem ještě přitvrdil: Řádky v mých programech obvykle nepřekračují 80 sloupců a třídy obvykle nepřekračují 65 řádek. Pro určité účely limituji délku řádek dokonce na 65 znaků, což mi nečiní žádné potíže.