Fórum Root.cz
Hlavní témata => Vývoj => Téma založeno: Arama 28. 08. 2015, 12:34:01
-
Ahojte, pordte prosim jak vytvorit 2 podminky pro while v pythonu.
while num1 == 0 AND num2 == 0:
pass
potrebuji aby while bezelo pokud budou obe promene mít hodnotu 0. dekuji
-
nejsem velkej programator a už vůbec ne v pythonu, ale co udělat bool z těch podmínek a pak do while dát bool? ;D
-
tohle?
x = 0
y = 0
while x is 0 and y is 0:
print "running"
-
Tohle porovnávání pomocí is není dobrý příklad. V tomto konkrétním případě kód sice bude fungovat správně, při testování na rovnost s čísly nad 256, s floaty a jinými objekty kód nebude fungovat správně nebo pouze někdy. Tento test na rovnost by měl používat ==.
-
Však to máš skoro dobře:
while num1 == 0 and num2 == 0:
pass
Doporučuji však použít závorky i tam, kde nejsou vyžadovány:
while (num1 == 0) and (num2 == 0):
pass
-
Tohle porovnávání pomocí is není dobrý příklad. V tomto konkrétním případě kód sice bude fungovat správně, při testování na rovnost s čísly nad 256, s floaty a jinými objekty kód nebude fungovat správně nebo pouze někdy. Tento test na rovnost by měl používat ==.
Ještě doplním: Bude to fungovat s malými čísly v dosavadním CPythonu a nikdo nezaručuje, že to tak bude navěky. Porovnávat pomocí "is" a "is not" má smysl porovnávat takto jedině singleton objekty (konkrétně None) nebo pro skutečné zjišťování identity dané instance. NIKDY čísla!
-
koukam co mu nemaka a on si tam cpe AND s velkyma pismenama
-
Však to máš skoro dobře:
while num1 == 0 and num2 == 0:
pass
Doporučuji však použít závorky i tam, kde nejsou vyžadovány:
while (num1 == 0) and (num2 == 0):
pass
A to jako proč?
-
Však to máš skoro dobře:
while num1 == 0 and num2 == 0:
pass
Doporučuji však použít závorky i tam, kde nejsou vyžadovány:
while (num1 == 0) and (num2 == 0):
pass
A to jako proč?
Bo tak to ma byt a tak je to spravne.
-
Však to máš skoro dobře:
while num1 == 0 and num2 == 0:
pass
Doporučuji však použít závorky i tam, kde nejsou vyžadovány:
while num1 == 0 and num2 == 0:
pass
A to jako proč?
Bo tak to ma byt a tak je to spravne.
Obojí funguje stene, závorky jsou tam zbytečně, proto nevidím jediný sebemenší důvod je tam používat, maximálně někdo může namítat čitelnost, ale mě osobně to příjde čitelnější bez zbytečných závorek...
-
Obojí funguje stene, závorky jsou tam zbytečně, proto nevidím jediný sebemenší důvod je tam používat
Protože je na první pohled jasné co a v jakém pořadí se vykoná, jak to pisatel myslel.
-
Obojí funguje stene, závorky jsou tam zbytečně, proto nevidím jediný sebemenší důvod je tam používat
Protože je na první pohled jasné co a v jakém pořadí se vykoná, jak to pisatel myslel.
A bez závorek ti to jasné není? Nepřipadám si jako nějakej génius, ale i tak mě sou jasná složitější ifi, či while a světe div se, bez závorek...
Ale asi chápu, že to bude stejná debata jako tabulátor Vs. mezery... :-)
-
A bez závorek ti to jasné není? Nepřipadám si jako nějakej génius, ale i tak mě sou jasná složitější ifi, či while a světe div se, bez závorek...
Ale asi chápu, že to bude stejná debata jako tabulátor Vs. mezery... :-)
To tedy vůbec není jasné :) Klidně se to může zpracovat takhle, podle toho jaký materiál si autoři programovacího jazyka zrovna šlehli:
0 and num2 -> false
num1 == false -> true
true == 0 -> false
Proto se tam všude píšou závorky, i když je to zdánlivě zbytečné. Diskuze nebude, protože je to jasné.
-
A bez závorek ti to jasné není? Nepřipadám si jako nějakej génius, ale i tak mě sou jasná složitější ifi, či while a světe div se, bez závorek...
Ale asi chápu, že to bude stejná debata jako tabulátor Vs. mezery... :-)
To tedy vůbec není jasné :) Klidně se to může zpracovat takhle, podle toho jaký materiál si autoři programovacího jazyka zrovna šlehli:
0 and num2 -> false
num1 == false -> true
true == 0 -> false
Proto se tam všude píšou závorky, i když je to zdánlivě zbytečné. Diskuze nebude, protože je to jasné.
Jenže autor se ptal ohledně pythonu, tedy bavíme se tady celou dobu o pythonu, kde závorky vyžadováné nejsou, proto je naprosto nesmyslné je tam psát, v tom je python právě krásný, nepoužívá bordel jako () ; {} atp... Takže diskuze že v jiném jazyce by to mohlo fungovat jinak je naprosto zcestná.
-
A bez závorek ti to jasné není? Nepřipadám si jako nějakej génius, ale i tak mě sou jasná složitější ifi, či while a světe div se, bez závorek...
Ale asi chápu, že to bude stejná debata jako tabulátor Vs. mezery... :-)
To tedy vůbec není jasné :) Klidně se to může zpracovat takhle, podle toho jaký materiál si autoři programovacího jazyka zrovna šlehli:
0 and num2 -> false
num1 == false -> true
true == 0 -> false
Proto se tam všude píšou závorky, i když je to zdánlivě zbytečné. Diskuze nebude, protože je to jasné.
Jakym zpusobem je ta podminka vyhodnocena je presne definovane, a zavorky tam nepatri, naopak neopodstatnene pouzivani zavorek muze spomalit vyhodnoceni.
Ale on by si tu nekdo musel precist aspon par veci o tom v cem dela a to preci po nikom nemuzeme chcit.
-
Obojí funguje stene, závorky jsou tam zbytečně, proto nevidím jediný sebemenší důvod je tam používat, maximálně někdo může namítat čitelnost, ale mě osobně to příjde čitelnější bez zbytečných závorek...
Nevidím důvod pro používání složených výrazů v objektových jazycích - držím se SRP. Máš pravdu v tom, že závorky jsou pak zcela zbytečné.
-
To, jestli se musí nebo nemusí psát závorky je dáno v každém programovacím jazyce tabulkou priorit operátorů (operator precedence table, pro Python 2.7 zde https://docs.python.org/2/reference/expressions.html (https://docs.python.org/2/reference/expressions.html) na konci stránky.) Operátory and a or jsou v tabulce výš, a tedy mají nižší prioritu, proto se nejprve vyhodnotí porovnání s vyšší prioritou a až pak "and" jak tazatel chce. Ve starších jazycích se ve stejné situaci závorky psát musí.
-
Operátory and a or jsou v tabulce výš, a tedy mají nižší prioritu, proto se nejprve vyhodnotí porovnání s vyšší prioritou a až pak "and" jak tazatel chce.
To víme a přesto nám to nebrání závorky používat. Máš nějaký další argument, proč tam ty závorky nedávat?
-
Operátory and a or jsou v tabulce výš, a tedy mají nižší prioritu, proto se nejprve vyhodnotí porovnání s vyšší prioritou a až pak "and" jak tazatel chce.
To víme a přesto nám to nebrání závorky používat. Máš nějaký další argument, proč tam ty závorky nedávat?
no sou tam na nic a proc delat zbytecne veci? to myslim jako argument bohate staci...
-
To víme a přesto nám to nebrání závorky používat. Máš nějaký další argument, proč tam ty závorky nedávat?
no sou tam na nic a proc delat zbytecne veci? to myslim jako argument bohate staci...
To platí až do doby, kdy narazíš na podmínku se složitějším výrazem od borce, který také sršel sebevědomím, ale nějak se mu ta logika rozjela a program vykazoval podivné chování. A pro člověka, který k tomu kódu přišel jako slepý k houslím a má to narychlo opravovat, je to úžasná radost. Vlastní zkušenost - taky Python.
-
To víme a přesto nám to nebrání závorky používat. Máš nějaký další argument, proč tam ty závorky nedávat?
no sou tam na nic a proc delat zbytecne veci? to myslim jako argument bohate staci...
To platí až do doby, kdy narazíš na podmínku se složitějším výrazem od borce, který také sršel sebevědomím, ale nějak se mu ta logika rozjela a program vykazoval podivné chování. A pro člověka, který k tomu kódu přišel jako slepý k houslím a má to narychlo opravovat, je to úžasná radost. Vlastní zkušenost - taky Python.
Někteří lidé rádi vypustí dvojici závorek jenom proto, aby pak na dvou řádcích komentářů popisovali, co ta podmínka vlastně má znamenat.
-
Operátory and a or jsou v tabulce výš, a tedy mají nižší prioritu, proto se nejprve vyhodnotí porovnání s vyšší prioritou a až pak "and" jak tazatel chce.
To víme a přesto nám to nebrání závorky používat. Máš nějaký další argument, proč tam ty závorky nedávat?
no sou tam na nic a proc delat zbytecne veci? to myslim jako argument bohate staci...
Komentáře jsou v programu také zbytečné a přesto je někteří programátoři píší. Proč, když nemají žádný vliv na běh programu?
Jsou nanic a proč dělat zbytečné věci? To myslím jako argument bohatě stačí...
-
Operátory and a or jsou v tabulce výš, a tedy mají nižší prioritu, proto se nejprve vyhodnotí porovnání s vyšší prioritou a až pak "and" jak tazatel chce.
To víme a přesto nám to nebrání závorky používat. Máš nějaký další argument, proč tam ty závorky nedávat?
no sou tam na nic a proc delat zbytecne veci? to myslim jako argument bohate staci...
Komentáře jsou v programu také zbytečné a přesto je někteří programátoři píší. Proč, když nemají žádný vliv na běh programu?
Jsou nanic a proč dělat zbytečné věci? To myslím jako argument bohatě stačí...
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.
-
Jenže autor se ptal ohledně pythonu, tedy bavíme se tady celou dobu o pythonu, kde závorky vyžadováné nejsou, proto je naprosto nesmyslné je tam psát, v tom je python právě krásný
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
-
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 sou tam na nic a proc delat zbytecne veci? to myslim jako argument bohate staci...
Kvůli přehlednosti, jako argument to bohatě stačí.
Existují projekty které se napíší a za tři měsíce vyhodí do stoupy, tam se tohle asi neocení.
Komentáře pouze označují místa, kde programátor udělal chybu nebo ještě něco nedodělal.
Normální komentáře označují místa, kde z kódu není jasně patrné o co jde nebo je tam nějaký nedořešený problém, tak si to programátor napsal do komentáře.
Psát komentář ke každému třetímu řádku zbytečnost je, to bezesporu.
-
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.
-
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.
Ja sa prave pozeram do zdrojaku vacsieho projektu a zatvorky tam su. Zdrojaky pise tim cca 10 - 12 ludi a kod je prehladny. Obsahuje komentare, aj zatvorky.
-
Viděl jsi už někdy zdrojáky nějakého většího projektu?
Furt. Dál si tady můžete žvanit o zbytečnosti závorek, já to s vámi myslel dobře.
-
Furt. Dál si tady můžete žvanit o zbytečnosti závorek, já to s vámi myslel dobře.
Jsi na špatném místě. Jdi do mailing listu kernelu a vysvětli vývojářům, že to dělají špatně, měli by podmínky závorkovat a myslíš to s nimi dobře.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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...
-
... 100 lidí 100 chutí...
-- dr. Hannibal Lecter
-
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]
[...]
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.
-
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.
-
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.
-
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
-
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.
-
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.
-
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.
Programovat podla poctu riadkov na monitore teda podla mna urcite nie je dobry napad.
Hovori ti nieco atomickost? Znovupouzitelnost? Prehladnost?
Funkcia, ktora ma 240 riadkov, bude tazko znovupouzitelna v uplne inom projekte. S prehladnostou moze mat tiez problem a atomickost zamerne nezmienujem.
Ja sa tiez rad drzim toho, ze funkcia by mala mat najviac 20 riadkov. Nie preto, ze to napisal nejaky Moore ci Green, ale preto, ze som prilis lenivy znovu vynachadzat koleso, rad teda pouzivam v novom projekte to co som uz pouzil pred niekolkymi mesiacmi v inom a, to ide ruka v ruke, som rad, ak po tych par mesiacoch viem prakticky okamzite povedat co stara funkcia robi. ;)
-
No vida, našel jsi to!
Nenašel, výčet parametrů VT100 není důkaz proč má mít funkce 20 řádek.
Funkcia, ktora ma 240 riadkov, bude tazko znovupouzitelna v uplne inom projekte.
Běžně mám funkce 200 řádek a běžně je používám v jiných projektech. Například když má switch 15 možností a každá možnost je na pět řádek + break, tak kvůli tobě nebudu dělit do pěti funkcí.
-
No vida, našel jsi to!
Nenašel, výčet parametrů VT100 není důkaz proč má mít funkce 20 řádek.
Našel jsi a otevřel tu učebnici. To je dobrý počin. Jen tak dál.
Funkcia, ktora ma 240 riadkov, bude tazko znovupouzitelna v uplne inom projekte.
Běžně mám funkce 200 řádek a běžně je používám v jiných projektech. Například když má switch 15 možností a každá možnost je na pět řádek + break, tak kvůli tobě nebudu dělit do pěti funkcí.
Ty ještě používáš break? 5 řádek u každé možnosti? Pak se nedivím, že máš funkce na 200 řádek. Vždyť se nesnažíš o znovupoužitelnost ani uvnitř toho switche.
-
Ty ještě používáš break? 5 řádek u každé možnosti? Pak se nedivím, že máš funkce na 200 řádek. Vždyť se nesnažíš o znovupoužitelnost ani uvnitř toho switche.
Věř tomu že jsem líný psát a je to nezbytně nutné.
Na případ kdy nepřekročíš limit 20 řádek na metodu a samotný switch má 20 možností se raději neptám, nechci to vědět s ohledem na mé duševní zdraví.
-
Ty ještě používáš break? 5 řádek u každé možnosti? Pak se nedivím, že máš funkce na 200 řádek. Vždyť se nesnažíš o znovupoužitelnost ani uvnitř toho switche.
Věř tomu že jsem líný psát a je to nezbytně nutné.
Na případ kdy nepřekročíš limit 20 řádek na metodu a samotný switch má 20 možností se raději neptám, nechci to vědět s ohledem na mé duševní zdraví.
Pokud pravidla porusujes z dobrych duvodu, je to OK. Ale to, co tu popisujes, mi pripomina spis typicky code smell. (mozna k tomu dobry duvod je, to bez kodu neposoudime, ale byl bych hodne podezrivavy)
-
Na případ kdy nepřekročíš limit 20 řádek na metodu a samotný switch má 20 možností se raději neptám, nechci to vědět s ohledem na mé duševní zdraví.
To je prosté: Jednoduše ten limit překročím. Metoda, kde switch má 40 možností, má délku třeba 45 řádek. Není však delší, než je nezbytně nutné a dodržuji pravidlo: Jedna možnost - jeden řádek - jeden příkaz. Čitelnost je pak luxusní.
-
Můžeš se vyjádřit k neutrálnímu kódu _negotiate(telnet_t *telnet, unsigned char telopt) https://github.com/seanmiddleditch/libtelnet/blob/master/libtelnet.c
Konkrétně jak se zlepší přehlednost rozdělením tohoto díla na cca 10 metod o 20 řádcích.
-
Můžeš se vyjádřit k neutrálnímu kódu _negotiate(telnet_t *telnet, unsigned char telopt) https://github.com/seanmiddleditch/libtelnet/blob/master/libtelnet.c
Konkrétně jak se zlepší přehlednost rozdělením tohoto díla na cca 10 metod o 20 řádcích.
Od oka rozdelit podle v tech mistech, kde jsou /*komentare*/ protoze ta si primo rikaji o pojmenovani misto komentovani?
Mozna je navic to cele zbytecne delat kodem, prijde mi to jako neco, co by lepe resilo hledani v tabulkach... ale nemam kontext.
-
Od oka rozdelit podle v tech mistech, kde jsou /*komentare*/ protoze ta si primo rikaji o pojmenovani misto komentovani?
OK, tak místa kde by se to mělo dělit už známe, teď ještě jak přesně to rozdělení zlepší přehlednost :)
Kontext máte v dalších souborech projektu na githubu a v RFC na telnet, máte ideální podmínky :)
-
Od oka rozdelit podle v tech mistech, kde jsou /*komentare*/ protoze ta si primo rikaji o pojmenovani misto komentovani?
OK, tak místa kde by se to mělo dělit už známe, teď ještě jak přesně to rozdělení zlepší přehlednost :)
Kontext máte v dalších souborech projektu na githubu a v RFC na telnet, máte ideální podmínky :)
sorry, ale nehodlam travit vecer refaktorovanim takoveho kodu
prehlednost se zlepsi, protoze najednou metoda vypada jako posloupnost par dobre pojmenovanych veci, takze kdyz ji ctes, tak mas tuseni o semantice a detaily si muzes rozkliknout pozdeji (a jen kdyz je potrebujes)?
-
Můžeš se vyjádřit k neutrálnímu kódu _negotiate(telnet_t *telnet, unsigned char telopt) https://github.com/seanmiddleditch/libtelnet/blob/master/libtelnet.c
Konkrétně jak se zlepší přehlednost rozdělením tohoto díla na cca 10 metod o 20 řádcích.
Před každým vnějším case je komentář. To je vhodné místo pro volání funkce. A když píši funkce, tak nemyslím proceduru.
Vezmu jeden switch:
/* in PROXY mode, just pass it thru and do nothing */
if (telnet->flags & TELNET_FLAG_PROXY) {
switch ((int)telnet->state) {
case TELNET_STATE_WILL:
NEGOTIATE_EVENT(telnet, TELNET_EV_WILL, telopt);
break;
case TELNET_STATE_WONT:
NEGOTIATE_EVENT(telnet, TELNET_EV_WONT, telopt);
break;
case TELNET_STATE_DO:
NEGOTIATE_EVENT(telnet, TELNET_EV_DO, telopt);
break;
case TELNET_STATE_DONT:
NEGOTIATE_EVENT(telnet, TELNET_EV_DONT, telopt);
break;
}
return;
}
Mírně ho zmodifikuji a vyčlením do funkce:
/* in PROXY mode, just pass it thru and do nothing */
if (telnet->flags & TELNET_FLAG_PROXY) {
return passThruProxy(telnet, telopt);
}
static int passThruProxy(telnet_t *telnet, unsigned char telopt);
switch ((int)telnet->state) {
case TELNET_STATE_WILL: return NEGOTIATE_EVENT(telnet, TELNET_EV_WILL, telopt);
case TELNET_STATE_WONT: return NEGOTIATE_EVENT(telnet, TELNET_EV_WONT, telopt);
case TELNET_STATE_DO: return NEGOTIATE_EVENT(telnet, TELNET_EV_DO, telopt);
case TELNET_STATE_DONT: return NEGOTIATE_EVENT(telnet, TELNET_EV_DONT, telopt);
}
}
Jak vidíš, zápis se zkrátil a čitelnost zlepšila.
Dále autor zapomíná příkazové závorky u jednořádkových ifů. To je hodně nebezpečné.
Ještě to chce rozbít vnořené switche tak, aby v každé funkci byl pouze jeden.
-
prehlednost se zlepsi, protoze najednou metoda vypada jako posloupnost par dobre pojmenovanych veci, takze kdyz ji ctes, tak mas tuseni o semantice a detaily si muzes rozkliknout pozdeji (a jen kdyz je potrebujes)?
Jak vidíš, zápis se zkrátil a čitelnost zlepšila.
Jak to hodláte udělat bylo jasné celou dobu, vnitřní switche dáte do pěti funkcí a budete si honit triko že máte šest krátkých funkcí. Bohužel ke zvýšení přehlednosti nedošlo, kód takto rozdělený je naopak přehledný méně, musí se zkoumat kdy se která funkce zavolá, co se jí předá a co se (případně) vrátí.
Přesvědčit jste mě nepřesvědčili.
-
Tak to je na tvem gustu. U nas bys asi pres reviews moc kodu neprotlacil, nejenom kvuli poctu radek, ale hlavne protoze ta metoda micha vic urovni abstrakce naraz ;)
A mam dojem, ze ani kernel nebo GNU coding standards to nesplnuje, ale ty jsem videl uz pred lety, tak se mozna pletu.
-
Jak vidíš, zápis se zkrátil a čitelnost zlepšila.
Jak to hodláte udělat bylo jasné celou dobu, vnitřní switche dáte do pěti funkcí a budete si honit triko že máte šest krátkých funkcí. Bohužel ke zvýšení přehlednosti nedošlo, kód takto rozdělený je naopak přehledný méně, musí se zkoumat kdy se která funkce zavolá, co se jí předá a co se (případně) vrátí.
Přesvědčit jste mě nepřesvědčili.
Aspoň vidíš, že nevařím z vody a že prezentuji styl, kterým skutečně programuji. Ten program je napsán procedurálním stylem, navíc s použitím #define. Refaktorovat by se to dalo, ale 1500 řádek by nějakou dobu trvalo. Nemohu za to, že neumíš pracovat s formálními parametry funkcí ani s návratovou hodnotou, protože na tom není dohromady co zkoumat. Nemám ambice spravovat telnet, výsledkem by byla jen tvá nespokojenost.
Pokud jsem tě nepřesvědčil, máš smůlu.
-
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...
Tak jistě. Protože se nikdo nikdy neuklepne v odsazení, případně při kopírování něčeho někam to nezkopíruje i s tím odsazením. A nikdo pak po mnoha letech nepátrá po tom, proč se sakra něco (ne)vyhodnocuje tam, kde by (ne)mělo. U těch if-ů apod. to je fakt na uražení pazoury.
-
Názory Vašeho osazenstva totálně vyhořivšího již při prvním kontaktu s reálným kódem jsou tímto trapné.
Prezentace ani práce nebyla požadována, pouze odpověď proč má být limit 20 řádek na metodu.
Nejlepší vysvětlení byl zatím ten kargo kult s VT100. Poznamenám si to, bude se to hodit jako historka.
-
Názory Vašeho osazenstva totálně vyhořivšího již při prvním kontaktu s reálným kódem jsou tímto trapné.
Prezentace ani práce nebyla požadována, pouze odpověď proč má být limit 20 řádek na metodu.
Tak chtěl jsi ten kód nebo nechtěl? Zkus si to v hlavě sjednotit, protože tyto dvě věty si odporují.
Nejlepší vysvětlení byl zatím ten kargo kult s VT100. Poznamenám si to, bude se to hodit jako historka.
Děláš, jako kdybys VT100 nebo jiný terminál nepoužíval. Souvislost s kargo kultem mi zcela uniká. Co si pod tímto pojmem vlastně představuješ? Mezi oblíbené kargo kulty můžeš zařadit například frameworky.
-
static int passThruProxy(telnet_t *telnet, unsigned char telopt);
switch ((int)telnet->state) {
case TELNET_STATE_WILL: return NEGOTIATE_EVENT(telnet, TELNET_EV_WILL, telopt);
case TELNET_STATE_WONT: return NEGOTIATE_EVENT(telnet, TELNET_EV_WONT, telopt);
case TELNET_STATE_DO: return NEGOTIATE_EVENT(telnet, TELNET_EV_DO, telopt);
case TELNET_STATE_DONT: return NEGOTIATE_EVENT(telnet, TELNET_EV_DONT, telopt);
}
}
Až na to, že se to vůbec nepřeloží, protože NEGOTIATE_EVENT nic nevrací. Taky jsi porušil single exit svaté přikázání, které najdeš v tvém oblíbeném Clean Code. A to vše jen proto, že vedeš nesmyslnou svatou válku proti break.
-
Názory Vašeho osazenstva totálně vyhořivšího již při prvním kontaktu s reálným kódem jsou tímto trapné.
My si kvalitu kodu hlidame. Je kvuli tomu min realny?
-
Jestli autorovi dotazu nešlo o to, aby se while provedl jen, jsou-li obě proměnné rovné nule,
while a == 0 and b == 0: se neprovede i když a = 0 a b = 1, to by musel podmínku přepsat takto
p1 = a == 0
p2 = b == 0
while p1 and p2:
pass
nebo
while not (a != 0 or b != 0):
pass
-
To je zase debata. Mrkněte se někdy na zdrojáky napsané Thompsonem, Kernighanem, Tannenbaumem, Wirthem nebo Knuthem. Všichni tihle lidi totiž dokázali napsat něco smysluplného a svým způsobem originálního, ale štábní kulturu nebral jako nějaké posvátné dogma ani jeden z nich. Naproti tomu mi rukama probíhají projekty, které jsou vystajlované přímo vzorově, ale jinak si nezaslouží víc, než být spláchnuty do hajzlíku. Protože jsou prostě blbě navržené a žádné formátovací dogma to v životě nespraví.
Jako na VŠ na praktikách. Byl tam takový pečlivý hujer, protokoly vždycky vzorově upravené, všechno krásné, ale bohužel v tom měl samá hausnumera a strávil na tom několikrát víc času než ostatní. On člověk by měl používat rozum spíš než nějaké tupé poučky.
Aneb "je sice agilní, ale přeci jen, je to vůl. Vždyť víš."
-
To je zase debata. Mrkněte se někdy na zdrojáky napsané Thompsonem, Kernighanem, Tannenbaumem, Wirthem nebo Knuthem. Všichni tihle lidi totiž dokázali napsat něco smysluplného a svým způsobem originálního, ale štábní kulturu nebral jako nějaké posvátné dogma ani jeden z nich. Naproti tomu mi rukama probíhají projekty, které jsou vystajlované přímo vzorově, ale jinak si nezaslouží víc, než být spláchnuty do hajzlíku. Protože jsou prostě blbě navržené a žádné formátovací dogma to v životě nespraví.
Jako na VŠ na praktikách. Byl tam takový pečlivý hujer, protokoly vždycky vzorově upravené, všechno krásné, ale bohužel v tom měl samá hausnumera a strávil na tom několikrát víc času než ostatní. On člověk by měl používat rozum spíš než nějaké tupé poučky.
Aneb "je sice agilní, ale přeci jen, je to vůl. Vždyť víš."
Docela dost slov na to, že jsi vlastně nic neřekl. Ale zakončil jsi to citátem, takže to asi bude OK.
-
No to je fakt debata... Taky vám k tomu něco povím... pokud si programujete sami, dělejte to tak, jak vám to vyhovuje, jak se vám to dobře čte, a jak vám to z klávesnice leze a hlavně netvrďte, že jste vzor dokonalosti a všichni to musí dělat stejně. Pokud se dotanete k většímu projektu a okusíte týmovou práci, buď rovnou dostanete popis používanýho coding stylu, který buď budete dodržovat, nebo si hledejte jinou práci, protože těžko se zavedenej tým bude učit podle jednoho novýho rejpala. Pokud projekt/tým žádnej ustálenej styl nemá, raději od toho jděte dobrovolně a hned, protože projekt pravděpodobně bude vypadat hůř, než dort od pejska a kočičky a hrozí vám značná psychická újma.
Jinak osobně třeba na počet řádků metody kašlu, protože pokud řeším komplikovanější úkol, kde je na místě ho rozsekat na menší části, raději si části odděluju komentem, protože pokud se vrhnu na přepisování do mnoha krátkých funkcí, mám problém s jejich pojmenováním tak, abych i po čase věděl, co jsem tím chtěl říct. Je to můj styl, není podle mě ani špatnej, ani správnej, mně to vyhovuje a nikomu to nenutím.
Jinak zábavná historka ze života - na SŠ jsme programovali v Turbo packalu, moje programy osahovaly vždy 4 pascalový příkazy, respektive direktivy: "begin, asm, end, end." a jinak bylo vše v ASM. Učitel z toho byl na prášky, na Packalu trval, a zakázal mi ASM v hlavním programu používat, nicméně bylo povoleno používat vlastní i "vypůjčené knihovny". Chudák dostal packalovskej program s jedním includem a posloupností asi 20ti záhadných volání, který nikdy neviděl. Program to byl krásnej a čitelnst pro něj stejně byla nulová :) Knihovna byla samozřejmě plná ASM, bez jediné nativní packalí funkce.
-
Až na to, že se to vůbec nepřeloží, protože NEGOTIATE_EVENT nic nevrací. Taky jsi porušil single exit svaté přikázání, které najdeš v tvém oblíbeném Clean Code. A to vše jen proto, že vedeš nesmyslnou svatou válku proti break.
O to přece nešlo, aby se to přeložilo. Stejně tak nešlo o to, že NEGOTIATE_EVENT není funkce, ale makro. Šlo o princip. Nechtělo se mi hledat vhodnou návratovou hodnotu, ale jsem si jist, že tam taková je - nejspíš objekt ev, který je skryt uvnitř makra ve formě vedlejšího efektu. Je na tom vidět, jak špatné je neuvážené používání maker.
Svaté přikázání Single exit je blbost.
So if you keep your functions small, then the occasional multiple return , break , or continue statement does no harm and can sometimes even be more expressive than the single-entry, single-exit rule.
To je jediná zmínka o single-exitu, kterou jsem v knize našel. Navíc je v protikladu s tím, co jsi napsal.
-
... Pokud se dotanete k většímu projektu a okusíte týmovou práci, buď rovnou dostanete popis používanýho coding stylu, který buď budete dodržovat, nebo si hledejte jinou práci, protože těžko se zavedenej tým bude učit podle jednoho novýho rejpala.
Popis coding stylu se z velké části dá uložit do git clean/smudge. Tím se o něj mohu přestat zajímat.
Jinak osobně třeba na počet řádků metody kašlu, protože pokud řeším komplikovanější úkol, kde je na místě ho rozsekat na menší části, raději si části odděluju komentem, protože pokud se vrhnu na přepisování do mnoha krátkých funkcí, mám problém s jejich pojmenováním tak, abych i po čase věděl, co jsem tím chtěl říct. Je to můj styl, není podle mě ani špatnej, ani správnej, mně to vyhovuje a nikomu to nenutím.
Špagety mám raději v hrnci a pak na talíři. Klidně si tak programuj, u mne bys neuspěl.
Jinak zábavná historka ze života - na SŠ jsme programovali v Turbo packalu, moje programy osahovaly vždy 4 pascalový příkazy, respektive direktivy: "begin, asm, end, end." a jinak bylo vše v ASM. Učitel z toho byl na prášky, na Packalu trval, a zakázal mi ASM v hlavním programu používat, nicméně bylo povoleno používat vlastní i "vypůjčené knihovny". Chudák dostal packalovskej program s jedním includem a posloupností asi 20ti záhadných volání, který nikdy neviděl. Program to byl krásnej a čitelnst pro něj stejně byla nulová :) Knihovna byla samozřejmě plná ASM, bez jediné nativní packalí funkce.
Použít tohle v zaměstnání, tak je to na vyhazov.
-
O to přece nešlo, aby se to přeložilo. Stejně tak nešlo o to, že NEGOTIATE_EVENT není funkce, ale makro. Šlo o princip. Nechtělo se mi hledat vhodnou návratovou hodnotu, ale jsem si jist, že tam taková je - nejspíš objekt ev, který je skryt uvnitř makra ve formě vedlejšího efektu. Je na tom vidět, jak špatné je neuvážené používání maker.
Z kódu který funguje, jsi udělal kód, který ani nejde přeložit a navíc je logicky špatně, vrací se tam hodnota něčeho, co vůbec žádnou návratovou hodnotu nemá. Jen proto, že z nějakého pochybného důvodu nemáš rád break, tak tam místo něho vrazil return, ale úplně blbě.
-
O to přece nešlo, aby se to přeložilo. Stejně tak nešlo o to, že NEGOTIATE_EVENT není funkce, ale makro. Šlo o princip. Nechtělo se mi hledat vhodnou návratovou hodnotu, ale jsem si jist, že tam taková je - nejspíš objekt ev, který je skryt uvnitř makra ve formě vedlejšího efektu. Je na tom vidět, jak špatné je neuvážené používání maker.
Z kódu který funguje, jsi udělal kód, který ani nejde přeložit a navíc je logicky špatně, vrací se tam hodnota něčeho, co vůbec žádnou návratovou hodnotu nemá. Jen proto, že z nějakého pochybného důvodu nemáš rád break, tak tam místo něho vrazil return, ale úplně blbě.
To jsi už psal, jen trochu v jiné podobě. A máš i nějaký závěr?
Můj závěr je jasný: Neuvážené použití použití maker udělá z programu noční můru, protože ho znečitelní. Proto také v moderních jazycích makra nejsou. Předělávat po někom takový program je nevděčnou činností, protože vždy se najde nějaký rejpal, kterému se líbí ta původní verze a kterému se nelze zavděčit.
-
Popis coding stylu se z velké části dá uložit do git clean/smudge. Tím se o něj mohu přestat zajímat.
Pořád ti zůstane nějaká část, o kterou se zajímat musíš a kterou zatím automaticky prostě neupravíš.
Špagety mám raději v hrnci a pak na talíři. Klidně si tak programuj, u mne bys neuspěl.
To je to, o čem mluvím. Co jednomu vyhovuje, druhýmu vadí. Až budu chtít u někoho uspět, budu muset dodržovat jeho pravidla. Žádný můj kód jsi neviděl, kecy o špagetách si můžeš odpustit, taky bezdůvodně netvrdím, že děláš sra*ky jenom proto, že mám blbou náladu. Pro mě osobně je na prvním místě funkčnost a optimalizace, vzhled a přehlednost kódu se tomu občas musí přizpůsobit a v takovým případě to částečně doháním komentama.
Použít tohle v zaměstnání, tak je to na vyhazov.
Problém byl v tom, že celej slavnej packal jsem uměl 10x líp než dotyčnej učitel a on to věděl. V té době jsem se začal zaměřovat na výkon a assembler byl nejlepší volbou. Konkrétně v té době a v tomto případě by jsi mě asi nevyhodil za to, že nepoužívám tvůj oblíbenej pascal, ale dal by jsi mi 2x tolik práce a 4x tolik peněz, protože programy byly 10x rychlejší i přesto, že jsem se vyžíval v programování grafických fičur, o kterých se standartním packalovským knihovnám ani nezdálo. Nicméně ano, byla to z mé strany mladická nerozvážnost a dost velká a zbytečná provokace.
-
To jsi už psal, jen trochu v jiné podobě. A máš i nějaký závěr?
Ano mám závěr. Vrtáš do kódu, který jsi nepochopil, svými změnami jsi ho rozbil a slepě a špatně aplikuješ poučky (žádný break, nemám rád gettery...) vyčtené z nějakých knih. Chybí ti zkušenosti. Celé to obhajuješ nekvalitou původního kódu, který ovšem narozdíl od toho tvého alespoň funguje.
-
Ano mám závěr. Vrtáš do kódu, který jsi nepochopil, svými změnami jsi ho rozbil a slepě a špatně aplikuješ poučky (žádný break, nemám rád gettery...) vyčtené z nějakých knih. Chybí ti zkušenosti. Celé to obhajuješ nekvalitou původního kódu, který ovšem narozdíl od toho tvého alespoň funguje.
Hmm. Proč by měl snippet, nad kterým jsem strávil sotva pár minut, fungovat? Abstrakce je přece mnohem důležitější, než konkrétní realizace. Přece jsi nechtěl, abych kompletně refaktoroval celých 1500 řádek kódu? To by byla práce na několik hodin, kterou by nikdo neocenil.
-
Hmm. Proč by měl snippet, nad kterým jsem strávil sotva pár minut, fungovat? Abstrakce je přece mnohem důležitější, než konkrétní realizace. Přece jsi nechtěl, abych kompletně refaktoroval celých 1500 řádek kódu? To by byla práce na několik hodin, kterou by nikdo neocenil.
Že nefunguje, by ani tak nevadilo. Horší je, že jsi to refaktoroval špatně. Chybně jsi aplikoval poučku "break je špatný" a vyhodil ho ze switche, kde naopak má velmi dobrý smysl. Místo toho jsi tam vrazil return, ale blbě, protože return nemá co vracet. Tím vznikla logická blbost, zavádíš návratovou hodnotu, která je k ničemu. Celé jsi to zatemnil a znepřehlednil.
-
Hmm. Proč by měl snippet, nad kterým jsem strávil sotva pár minut, fungovat? Abstrakce je přece mnohem důležitější, než konkrétní realizace. Přece jsi nechtěl, abych kompletně refaktoroval celých 1500 řádek kódu? To by byla práce na několik hodin, kterou by nikdo neocenil.
Jinak přesně to jsem měl na mysli... funkčnost je vždy na prvním místě... udělat kód "hezčí" za cenu jeho znefunkčnění nebude ta správná cesta a je jedno, jestli se jedná o pár řádků na ukázku, nebo celý projekt.
-
No vida, našel jsi to!
Nenašel, výčet parametrů VT100 není důkaz proč má mít funkce 20 řádek.
Funkcia, ktora ma 240 riadkov, bude tazko znovupouzitelna v UPLNE INOM projekte.
Běžně mám funkce 200 řádek a běžně je používám v jiných projektech. Například když má switch 15 možností a každá možnost je na pět řádek + break, tak kvůli tobě nebudu dělit do pěti funkcí.
Kvoli mne si nic nedel. Del si to kvoli sebe a svojmu usetrenemu casu. Ja ti hovorim co vychadza zo skusenosti.
Mozes sa hadat, ale nezmenis na tom nic.
Ale ozaj by som teda rad videl funkciu s 200 riadkami, ktora je pouzitelna v UPLNE INOM projekte.
-
Kvoli mne si nic nedel. Del si to kvoli sebe a svojmu usetrenemu casu. Ja ti hovorim co vychadza zo skusenosti.
Mozes sa hadat, ale nezmenis na tom nic.
Ale ozaj by som teda rad videl funkciu s 200 riadkami, ktora je pouzitelna v UPLNE INOM projekte.
Zajímá mě z kterého klobouku se vyčarovalo to "20 řádek". Proč to není třeba "půl obrazovky", "jedna obrazovka", "jedna A4" a podobně. Zkušeností mám dostatek.
Nepřekvapivě se stavový automat podobné velikosti implementuje v úplně jiném projektu a úplně stejně.
-
Zajímá mě z kterého klobouku se vyčarovalo to "20 řádek". Proč to není třeba "půl obrazovky", "jedna obrazovka", "jedna A4" a podobně. Zkušeností mám dostatek.
Nepřekvapivě se stavový automat podobné velikosti implementuje v úplně jiném projektu a úplně stejně.
Protoze je to "tak akorat"? Protoze dvaadvacet je porad OK, ale padesat uz ne a osmnact je pro podobna pravidla blbe cislo? Protoze kazda obrazovka je jina?
A nenapadlo te mit stavovy automat spis v datech nez v kodu?
-
Zajímá mě z kterého klobouku se vyčarovalo to "20 řádek". Proč to není třeba "půl obrazovky", "jedna obrazovka", "jedna A4" a podobně. Zkušeností mám dostatek.
Nepřekvapivě se stavový automat podobné velikosti implementuje v úplně jiném projektu a úplně stejně.
Protoze je to "tak akorat"? Protoze dvaadvacet je porad OK, ale padesat uz ne a osmnact je pro podobna pravidla blbe cislo? Protoze kazda obrazovka je jina?
A nenapadlo te mit stavovy automat spis v datech nez v kodu?
že by třeba optimalizace? Pokud se jedná o statické hodnoty, je rozhodně rychlejší udělat to přes case, než řešit nějaký data, smyčky atd. A čitelnost kódu bude asi v tomto případě většinou lepší s case. Poučky jsou naprd, jejich slepá aplikace je kolikrát kontraproduktivní a zlikvidovat si přehlednost proto, že někdo tvrdí, že 20 řádků na metodu je tak akorát, to mi nepřijde úplně správný.
Mimochodem, několikrát zmíněná kniha Clean Code vede ke zbytečnému fanatismu a chybí jí už v předmluvě velké varování, že autor není Bůh a že kniha se skládá z jeho osobních názorů, které sice nejsou zcela špatné, ale rozhodně se nejedná o žádnou Bibli, Korán, nebo etalon programování.
-
Dám sem alternativu ke Clean Code, něco z reálného života: http://www.stroustrup.com/JSF-AV-rules.pdf
Coding standards z leteckého průmyslu, v mnoha ohledech je to pochopitelně mnohem restriktivnější než Clean Code.
A switch se tam řeší:
All functions shall have a cyclomatic complexity number of 20 or less.
Rationale:
Limit function complexity. See AV Rule 3 in Appendix A for additional details.
Exception:
A function containing a switch statement with many case labels may exceed this limit.
A break se tam taky řeší:
The break statement shall not be used (except to terminate the cases of a switch statement).
-
Vždy a všude se najde vyjímka :)
Jinak příklad z nedávné minulosti, jednalo se o modul pro e-shop OpenCart, respektive jednu relativně triviální funkci, nic velkýho, cca 200 řádků, z toho 50 je natahování language files, nějaký definování použitých modelů, serepetičky kolem, čistej samotnej kód, kterej něco dělá, má ani ne 100 řádků a z nich většina tahá nějaký data z různých míst pomocí již hotových funkcí z natažených modelů a na základě pár podmínek vypadne nějakej výsledek (respektive vrátí jeden array). Rozsekat to celý na další části by sice bylo otázkou pár minut, nicméně nevím, co bych tím konkrétně získal. Asi funkci, která volá další funkce, který volají interní funkce... to je tak akorát noční můra při debugování. Možná to bude hezčí opticky, ale celkově to čitelnosti kódu nijak zvlášť nepomůže.
-
Vždy a všude se najde vyjímka :)
Jinak příklad z nedávné minulosti, jednalo se o modul pro e-shop OpenCart, respektive jednu relativně triviální funkci, nic velkýho, cca 200 řádků, z toho 50 je natahování language files, nějaký definování použitých modelů, serepetičky kolem, čistej samotnej kód, kterej něco dělá, má ani ne 100 řádků a z nich většina tahá nějaký data z různých míst pomocí již hotových funkcí z natažených modelů a na základě pár podmínek vypadne nějakej výsledek (respektive vrátí jeden array). Rozsekat to celý na další části by sice bylo otázkou pár minut, nicméně nevím, co bych tím konkrétně získal. Asi funkci, která volá další funkce, který volají interní funkce... to je tak akorát noční můra při debugování. Možná to bude hezčí opticky, ale celkově to čitelnosti kódu nijak zvlášť nepomůže.
ti nevim, ale
foo() {
loadImages()
bar = prepareData()
return stuff(bar)
}
mi prijde o dost prehlednejsi nez foo() se dvema sty radky. Nemluve ani o tom, ze vyjimka ze stuff() je popisnejsi nez vyjimka z foo() a ze vazne netusim, jak chces na neco o dvou stech radkach psat testy..
Co je na tom nocni mura pro debugovani? To nemas IDE s debuggerem?
-
Protoze je to "tak akorat"? Protoze dvaadvacet je porad OK, ale padesat uz ne a osmnact je pro podobna pravidla blbe cislo? Protoze kazda obrazovka je jina?
To už tady bylo, 20 řádků je "tak akorát" na VT100. Na mém průměrném LCD vidím 55 řádků. Dle selského rozumu by "tak akorát" bylo 55.
Coding standards z leteckého průmyslu, v mnoha ohledech je to pochopitelně mnohem restriktivnější než Clean Code.
Aerospace, military, automotive a life-support je ve všech ohledech jiný svět, vůbec nemá smysl to sem tahat.
Mimochodem ani v automotive nemají limit na 20 řádků, přečti si to pořádně.
-
Protoze je to "tak akorat"? Protoze dvaadvacet je porad OK, ale padesat uz ne a osmnact je pro podobna pravidla blbe cislo? Protoze kazda obrazovka je jina?
To už tady bylo, 20 řádků je "tak akorát" na VT100. Na mém průměrném LCD vidím 55 řádků. Dle selského rozumu by "tak akorát" bylo 55.
Ty nechapes, ze to neni zdaleka jenom o viditelnosti na obrazovce, ale o komplexite a o tom, mit v jedne funkci praci s jednou veci na jedne urovni abstrakce? Tohle neni zadne svate pravidlo, neznam team, kde by ti za 22 radku nekdo utrhnul hlavu a naopak samo o sobe to nestaci. Je to hlavne hint na tema, ze cim vic tech dvacet (sam bych byl spis pro deset, ale to je jina) radku prekracujes, tim vic vzrusta pravdepodobnost, ze neco delas blbe.
-
Aerospace, military, automotive a life-support je ve všech ohledech jiný svět, vůbec nemá smysl to sem tahat.
Mimochodem ani v automotive nemají limit na 20 řádků, přečti si to pořádně.
Proč to sem nemá smysl tahat? V aerospace neprogramují? Kde jsem psal o nějakém limitu na 20 řádků?
-
Ty nechapes, ze to neni zdaleka jenom o viditelnosti na obrazovce, ale o komplexite a o tom, mit v jedne funkci praci s jednou veci na jedne urovni abstrakce? Tohle neni zadne svate pravidlo, neznam team, kde by ti za 22 radku nekdo utrhnul hlavu a naopak samo o sobe to nestaci. Je to hlavne hint na tema, ze cim vic tech dvacet (sam bych byl spis pro deset, ale to je jina) radku prekracujes, tim vic vzrusta pravdepodobnost, ze neco delas blbe.
Žádná komplexita, jasně bylo řečeno 20 řádků.
S tvrzením že v jedné funkci má být max. 20 důležitých věcí, bych problém neměl. Shodou okolností má taková funkce zhruba 30-50 řádků :)
-
Proč to sem nemá smysl tahat? V aerospace neprogramují?
Je to naprosto jiný svět. Je to rozdíl jako Země a Mars.
-
Je to naprosto jiný svět. Je to rozdíl jako Země a Mars.
Jiný než co? Programuje se v C(++), coding standards jsou značně restriktivnější. Já automotive dělal a nevidím důvod, proč to sem nedat.
-
Ty nechapes, ze to neni zdaleka jenom o viditelnosti na obrazovce, ale o komplexite a o tom, mit v jedne funkci praci s jednou veci na jedne urovni abstrakce? Tohle neni zadne svate pravidlo, neznam team, kde by ti za 22 radku nekdo utrhnul hlavu a naopak samo o sobe to nestaci. Je to hlavne hint na tema, ze cim vic tech dvacet (sam bych byl spis pro deset, ale to je jina) radku prekracujes, tim vic vzrusta pravdepodobnost, ze neco delas blbe.
Žádná komplexita, jasně bylo řečeno 20 řádků.
S tvrzením že v jedné funkci má být max. 20 důležitých věcí, bych problém neměl. Shodou okolností má taková funkce zhruba 30-50 řádků :)
Ale ano, komplexita. Pretoze ak sa drzis +- 20 riadkov vo funkcii, tak mas velku sancu sa drzat principu atomickych funkcii (teda funkcii, ktore robia len jednu jedinu vec). A cim mas viac takych funkcii, tym tazsie do kodu zavedis chybu a ak uz ano, tak ju lahsie odladis a lahsie na nieco take napises testy. Nehovoriac o tom, ze mozes pisat testy aj na tie samotne atomicke funkcie, ktore vykonavaju jednotlive casti tvojej 200 riadkovej funkcie. Divide and conquer.
-
No tak to vidíš špatně, dál se o automotive nebavím.
Ale ano, komplexita. Pretoze ak sa drzis +- 20 riadkov vo funkcii
Tak komplexita 20 nebo počet řádků 20 ? Vyber si jedno nebo druhé :)
-
Žádná komplexita, jasně bylo řečeno 20 řádků.
S tvrzením že v jedné funkci má být max. 20 důležitých věcí, bych problém neměl. Shodou okolností má taková funkce zhruba 30-50 řádků :)
To asi bylo v kontextu k nejakemu jazyku (aspon doufam). Protoze jsem snad jeste ani nevidel obri funkci
ve Forthu ci APL (napriklad), ktera by tech 20 radku mela, tam je i 5 radku moc (ostatne klasicke Forthy
pouzivaji/pouzivaly logickou obrazovku 64x16 znaku, takze by se tam ani ta funkce nevesla).
-
No tak to vidíš špatně, dál se o automotive nebavím.
Ty to vidíš špatně a dál se o tom nebavím. Přeloženo: došly mi argumenty, takže se o tom dál radši nebudu bavit.
-
No tak to vidíš špatně, dál se o automotive nebavím.
Ale ano, komplexita. Pretoze ak sa drzis +- 20 riadkov vo funkcii
Tak komplexita 20 nebo počet řádků 20 ? Vyber si jedno nebo druhé :)
Cely cas je rec o 20 riadkoch. Neviem co dalsie myslis.
-
Žádná komplexita, jasně bylo řečeno 20 řádků.
S tvrzením že v jedné funkci má být max. 20 důležitých věcí, bych problém neměl. Shodou okolností má taková funkce zhruba 30-50 řádků :)
To asi bylo v kontextu k nejakemu jazyku (aspon doufam). Protoze jsem snad jeste ani nevidel obri funkci
ve Forthu ci APL (napriklad), ktera by tech 20 radku mela, tam je i 5 radku moc (ostatne klasicke Forthy
pouzivaji/pouzivaly logickou obrazovku 64x16 znaku, takze by se tam ani ta funkce nevesla).
Podobne trebas Haskell, tam clovek taky tak nejak automaticky dojde k malym kompaktnim funkcim.
-
A co v případě, že už mám funkce na získání potřebných dat k dispozici (např. pokud tvořím modul) a potřebuji pouze různá data vzít, poskládat a vrátit výsledek? Mám si je skládat po 20 ti řádcích na funkci do jednoho public array, nebo si mám data rozdělit do několika arrays, ty potom sloučit a vrátit, nebo si mám array naskládat v jednom řádku s délkou několik set až tisíc znaků a s použitím zkrácených ifů, nebo si mám znovu napsat již existující systémové funkce nějak jinak, nebo si mám udělat jednu funkci getDataParts, která bude mít sice třeba 100 řádků a na konci return, ale hlavní funkce getData už bude mít "jenom" $cosi=getDataParts a return, nebo rovnou udělat jednu 100 řádkovou funkci s jedním returnem?
Nebo další varianta, prohlásit, že je systém debilní a žádný modul do něj dělat nebudu, protože bych musel porušit "svatá pravidla" o víc, než někým tolerovaný kousek? A jaký je ten tolerovaný kousek? 20 řádků by mělo být, 22 ještě dobrý, 23 s přimhouřeným okem, 24 se zavřenýma oběma očima a 25 už striktně ne?
Já to vidím takhle... nas*at na tyhle "poučky". Sice jsem programátor samouk a většinou když něco dělám, tak jen pro sebe nebo pro známý, ale na druhou stranu už programuju dobrých 25 let a moc dobře vím, jak napsat program tak, abych se v něm i s časovým odstupem sám v pohodě vyznal. A když se v tom vyzná takovej amatér jako já, pro profíka by to asi taky neměl být problém, kdyby se k tomu někdy nějakej omylem dostal.
Když chce někdo programovat, je to o svobodě, o způsobu myšlení. Jestli to někdo dělá jenom pro peníze a nebaví ho to, poučky mu nepomůžou, stejně nikdy nebude dost dobrej. Pokud to dělám mimo jiné i proto, že mě to baví, poučky jsou omezující. Za traktorem taky nepojedu hodinu dvacítkou po jinak prázdné přehledné silnici jenom proto, že tam nějakej debil omylem načmáral plnou čáru.
-
A co v případě, že už mám funkce na získání potřebných dat k dispozici (např. pokud tvořím modul) a potřebuji pouze různá data vzít, poskládat a vrátit výsledek? Mám si je skládat po 20 ti řádcích na funkci do jednoho public array, nebo si mám data rozdělit do několika arrays, ty potom sloučit a vrátit, nebo si mám array naskládat v jednom řádku s délkou několik set až tisíc znaků a s použitím zkrácených ifů, nebo si mám znovu napsat již existující systémové funkce nějak jinak, nebo si mám udělat jednu funkci getDataParts, která bude mít sice třeba 100 řádků a na konci return, ale hlavní funkce getData už bude mít "jenom" $cosi=getDataParts a return, nebo rovnou udělat jednu 100 řádkovou funkci s jedním returnem?
Nebo další varianta, prohlásit, že je systém debilní a žádný modul do něj dělat nebudu, protože bych musel porušit "svatá pravidla" o víc, než někým tolerovaný kousek? A jaký je ten tolerovaný kousek? 20 řádků by mělo být, 22 ještě dobrý, 23 s přimhouřeným okem, 24 se zavřenýma oběma očima a 25 už striktně ne?
Já to vidím takhle... nas*at na tyhle "poučky". Sice jsem programátor samouk a většinou když něco dělám, tak jen pro sebe nebo pro známý, ale na druhou stranu už programuju dobrých 25 let a moc dobře vím, jak napsat program tak, abych se v něm i s časovým odstupem sám v pohodě vyznal. A když se v tom vyzná takovej amatér jako já, pro profíka by to asi taky neměl být problém, kdyby se k tomu někdy nějakej omylem dostal.
Když chce někdo programovat, je to o svobodě, o způsobu myšlení. Jestli to někdo dělá jenom pro peníze a nebaví ho to, poučky mu nepomůžou, stejně nikdy nebude dost dobrej. Pokud to dělám mimo jiné i proto, že mě to baví, poučky jsou omezující. Za traktorem taky nepojedu hodinu dvacítkou po jinak prázdné přehledné silnici jenom proto, že tam nějakej debil omylem načmáral plnou čáru.
Co ze to delas s tim polem?
-
Ty to vidíš špatně a dál se o tom nebavím. Přeloženo: došly mi argumenty, takže se o tom dál radši nebudu bavit.
Došla mi energie vysvětlovat, že opravdu zdejší diskuze nemá nic společného s aerospace a uniká mi proč to tady vůbec někdo zatáhnul.
Cely cas je rec o 20 riadkoch. Neviem co dalsie myslis.
Počet řádků a komplexita jsou dvě různé věci, motáš se v tom stále.
20 řádků = cargo cult z VT100
komplexita 20 = logické racionální zdůvodnění
-
Vytahat data z různýma funkcema a z nich udělat pole (do toho pár podmínek). Jenom je toho prostě na řádky moc, skládat to za sebe na řádek jenom kvůli počtu řádků je taky blbost a dělit to na víc částí je totálně nelogický.
Ale to je celkem jedno, jde o to, že pravidla jsou doporučující, nikoliv zavazující. Vždycky se najde velmi dobrej důvod, proč je porušit.
-
Zajímá mě z kterého klobouku se vyčarovalo to "20 řádek". Proč to není třeba "půl obrazovky", "jedna obrazovka", "jedna A4" a podobně. Zkušeností mám dostatek.
Daly by se použít fuzzy pojmy, ale když někomu řekneš, že funkce nemá mít příliš mnoho řádek, okamžitě se zeptá, co je to "příliš mnoho". Tak se udělala nějaká statistika z úspěšných aplikací a zjistilo se, že v těch úspěšných nebývají funkce delší než těch 20 řádek.
Z toho tedy vyplývá, že čím ty funkce či metody budeš mít delší, tím menší je pravděpodobnost, že uděláš úspěšnou aplikaci. Obráceně to však neplatí! Krátké funkce ti nijak nezaručují, že aplikace bude úspěšná - pouze snižují pravděpodobnost, že něco zvoráš a nevšimneš si toho.
Dlouhé funkce se navíc hodně blbě testují. Když však provozuješ TDD, tak dlouhé funkce zpravidla ani nevznikají.
-
Pořád řešíte počet řádků funkce, ale to není moc dobrá metrika. Mnohem lepší je cyklomatická složitost funkce.
Když budu mít 1000 řádkovou funkci s cyklomatickou složitostí 1, tak ji můžu rozdělit do 100 fukcí po 10 řádcích, ale jejich cyklomatická složitost bude pořád 1. Mentální kapacita nutná k pochopení jedné funkce s 1000 řádky nebo 100 funkcí s 10 řádky je pořád stejná. Nic moc tím rozdělením neziskám.
Když budu mít 1000 řádkovou funci s cyklomatickou složitostí 100, tak vím, že je to opravdu blbě. Tohle nikdo nikdy nepochopí (ani autor). Tady je jediná cesta, rozdělit to do více malých funkcí s malou cyklomatickou složitostí.
-
Pořád řešíte počet řádků funkce, ale to není moc dobrá metrika. Mnohem lepší je cyklomatická složitost funkce.
Když budu mít 1000 řádkovou funkci s cyklomatickou složitostí 1, tak ji můžu rozdělit do 100 fukcí po 10 řádcích, ale jejich cyklomatická složitost bude pořád 1. Mentální kapacita nutná k pochopení jedné funkce s 1000 řádky nebo 100 funkcí s 10 řádky je pořád stejná. Nic moc tím rozdělením neziskám.
Když budu mít 1000 řádkovou funci s cyklomatickou složitostí 100, tak vím, že je to opravdu blbě. Tohle nikdo nikdy nepochopí (ani autor). Tady je jediná cesta, rozdělit to do více malých funkcí s malou cyklomatickou složitostí.
S tímto souhlasím, konečně jsme se k něčemu dobrali :)
-
Došla mi energie vysvětlovat, že opravdu zdejší diskuze nemá nic společného s aerospace a uniká mi proč to tady vůbec někdo zatáhnul.
Bavíme se o coding standards? Takže v čem je problém s coding standards z aerospace? Že jsou moc restriktivní pro nějaké jiné použití? No tak vezmu jen ty pravidla, která se mi hodí pro moji aplikaci. I tak jich zbyde dost. Přesně tohle doporučuje i Bjarne Stroustrup, mimochodem on je spoluautorem těch aerospace coding standards: http://www.stroustrup.com/bs_faq2.html#coding-standard
A proč jsem to sem dával? Protože pořád řešíte velikost switche a aerospace coding standards, které lze považovat za nejvíce restriktivní, ji v podstatě neomezují.
-
A proč jsem to sem dával? Protože pořád řešíte velikost switche a aerospace coding standards, které lze považovat za nejvíce restriktivní, ji v podstatě neomezují.
Tak tím se to vysvětluje a je to OK.
-
Pořád řešíte počet řádků funkce, ale to není moc dobrá metrika. Mnohem lepší je cyklomatická složitost funkce.
Když budu mít 1000 řádkovou funkci s cyklomatickou složitostí 1, tak ji můžu rozdělit do 100 fukcí po 10 řádcích, ale jejich cyklomatická složitost bude pořád 1. Mentální kapacita nutná k pochopení jedné funkce s 1000 řádky nebo 100 funkcí s 10 řádky je pořád stejná. Nic moc tím rozdělením neziskám.
Když budu mít 1000 řádkovou funci s cyklomatickou složitostí 100, tak vím, že je to opravdu blbě. Tohle nikdo nikdy nepochopí (ani autor). Tady je jediná cesta, rozdělit to do více malých funkcí s malou cyklomatickou složitostí.
Hááálelůja, přesně tak, jenom ještě doplním, že i tu jednoduchou 1000 řádkovou funkci může (a nemusí ) být vhodné rozdělit kvůli opakujícím se částem kódu, záleží na situaci a na "zdravém selském rozumu", nikoliv na 20-ti řádkové poučce.
-
A co v případě, že už mám funkce na získání potřebných dat k dispozici (např. pokud tvořím modul) a potřebuji pouze různá data vzít, poskládat a vrátit výsledek? Mám si je skládat po 20 ti řádcích na funkci do jednoho public array, nebo si mám data rozdělit do několika arrays, ty potom sloučit a vrátit, nebo si mám array naskládat v jednom řádku s délkou několik set až tisíc znaků a s použitím zkrácených ifů, nebo si mám znovu napsat již existující systémové funkce nějak jinak, nebo si mám udělat jednu funkci getDataParts, která bude mít sice třeba 100 řádků a na konci return, ale hlavní funkce getData už bude mít "jenom" $cosi=getDataParts a return, nebo rovnou udělat jednu 100 řádkovou funkci s jedním returnem?
Dlouhé řádky ti nepomohou, když máš soft limit na 65 znacích jako já :-)
Základem je kvalitní dekompozice aplikace. Určitě nemáš sekvenci 200 příkazů, které by nebyly nějak grupovány do podmíněných bloků či cyklů. Vnořené cykly jsou nejviditelnějšími objekty pro refaktorování. Nebývá mnoho důvodů dva vnořené cykly nechávat v jedné funkci.
Stejně tak vnořené switche, tolik typické pro konečné automaty, se dají logicky rozdělit do dvou vrstev, kdy vrchní vrstva podle hodnoty stavu volá funkci druhé vrstvy a předá jí vstupní symbol. Druhá vrstva ten symbol zpracuje a do první vrstvy vrátí returnem hodnotu nového stavu. Každý stav tak má svoji vlastní funkci. Úplně stejně jak máš ten automat rozkreslený na papíře.
Konečný automat se skutečně dá efektně i efektivně řešit na nějaké datové struktuře - nejlépe na kolekci objektů. A není to pomalé - zkus si to změřit. Dokonce to bývá rychlejší než vnořené switche, zejména u nenumerických klíčů. Místo sekvenčního porovnávání jednotlivých case se totiž používá vektor pointerů.
Pokud tedy budeš refaktorovat funkci o 200 řádcích, určitě to nedělej horizontálně, ale vertikálně. Klidně i do tří nebo více vrstev. Každý vnořený scope je kandidátem na nižší vrstvu. Dokonce i dvacetiřádkové funkce se dají rozvrstvit až na jednotlivé řádky, ale v rámci zachování zdravého rozumu je dobré se zastavit právě u těch 5-20 řádků, které by se už dále členit moc neměly, protože pak už se čitelnost nezvyšuje, ale opět snižuje.
Nemusíš se bát, že se tím program nějak zpomalí. Když se podíváš pod pokličku dnešních kompilátorů, tak zjistíš, že jejich optimalizátory často rozbalují volání drobných funkcí tak, jako kdyby to byla makra. Typicky gettery/settery nahrazují přímým přístupem k proměnné, přístupová práva řeší už v době překladu.
-
A proč jsem to sem dával? Protože pořád řešíte velikost switche a aerospace coding standards, které lze považovat za nejvíce restriktivní, ji v podstatě neomezují.
Aerospace coding standards však zcela jistě řeší cykly uvnitř switchů a switche uvnitř cyklů stejně jako switch uvnitř switche, podmínku uvnitř podmínky a cyklus uvnitř cyklu. To jsou prostě kandidáti na rozdělení do vrstev.
-
Dlouhé řádky ti nepomohou, když máš soft limit na 65 znacích jako já :-)
Máš k tomu nějaký kruciální důkaz jako zmíněná cyklomatická složitost, nebo je to zase jenom cargo cult z VT100 nebo VGA? :)
Abychom se nezdržovali, tak na standardním LCD za $100 je vidět 50x200 znaků kódu najednou, po odpočtení ostatních oken a menu.
-
Dlouhé řádky ti nepomohou, když máš soft limit na 65 znacích jako já :-)
Máš k tomu nějaký kruciální důkaz jako zmíněná cyklomatická složitost, nebo je to zase jenom cargo cult z VT100 nebo VGA? :)
Abychom se nezdržovali, tak na standardním LCD za $100 je vidět 50x200 znaků kódu najednou, po odpočtení ostatních oken a menu.
Na svém LCD monitoru s rozlišením 1280×1024 vidím v editoru 40 řádek a na každém z nich 115 znaků. Když však kus programu pošlu do nějakého fóra, tak těch max 65 znaků na řádek je tak akorát na to, aby se vešel mezi ty pruhy reklam po stranách. Máš snad nějaký pádný důvod k tomu, aby ty řádky byly delší než 65 znaků? Dlouhé řádky mi prostě vadí při čtení - při jejich správném zalomení to vypadá mnohem lépe, lépe se mi s nimi pracuje a přitom mě nijak neomezují.
Pokud je 300znakový příkaz správně zalomen třeba do 6 řádek, klidně mu mohu přidat dalších 100 znaků aniž bych nějak ohrozil jeho čitelnost. Pouze se mi zápis funkce či metody prodlouží o 2-3 řádky. Pokud tu nudli nacpeš na jeden 400znakový řádek ... Už jsi někdy pročítal diff takových zdrojáků?
Co máš pořád s tím kargo kultem? Evidentně vůbec netušíš, co to je. Nebo si snad myslíš, že se celý den modlím, aby mi někdo přivezl lepší monitor nebo aby někdo opravil chybu či omezení v nějakém oblíbeném frameworku?
-
Dlouhé řádky ti nepomohou, když máš soft limit na 65 znacích jako já :-)
Máš k tomu nějaký kruciální důkaz jako zmíněná cyklomatická složitost, nebo je to zase jenom cargo cult z VT100 nebo VGA? :)
Abychom se nezdržovali, tak na standardním LCD za $100 je vidět 50x200 znaků kódu najednou, po odpočtení ostatních oken a menu.
Na svém LCD monitoru s rozlišením 1280×1024 vidím v editoru 40 řádek a na každém z nich 115 znaků. Když však kus programu pošlu do nějakého fóra, tak těch max 65 znaků na řádek je tak akorát na to, aby se vešel mezi ty pruhy reklam po stranách. Máš snad nějaký pádný důvod k tomu, aby ty řádky byly delší než 65 znaků? Dlouhé řádky mi prostě vadí při čtení - při jejich správném zalomení to vypadá mnohem lépe, lépe se mi s nimi pracuje a přitom mě nijak neomezují.
Pokud je 300znakový příkaz správně zalomen třeba do 6 řádek, klidně mu mohu přidat dalších 100 znaků aniž bych nějak ohrozil jeho čitelnost. Pouze se mi zápis funkce či metody prodlouží o 2-3 řádky. Pokud tu nudli nacpeš na jeden 400znakový řádek ... Už jsi někdy pročítal diff takových zdrojáků?
Co máš pořád s tím kargo kultem? Evidentně vůbec netušíš, co to je. Nebo si snad myslíš, že se celý den modlím, aby mi někdo přivezl lepší monitor nebo aby někdo opravil chybu či omezení v nějakém oblíbeném frameworku?
https://en.wikipedia.org/wiki/Cargo_cult_programming
"applying a design pattern or coding style blindly without understanding the reasons behind that design principle"
IMHO celkem sedí, viz fiasko s return ze switche
-
Aerospace coding standards však zcela jistě řeší cykly uvnitř switchů a switche uvnitř cyklů stejně jako switch uvnitř switche, podmínku uvnitř podmínky a cyklus uvnitř cyklu. To jsou prostě kandidáti na rozdělení do vrstev.
Ne tohle se tam opravdu neřeší, přečti se ten coding standard. Ale řeší se tam maximální délka řádku a maximální délka funkce:
Source lines will be kept to a length of 120 characters or less.
Any one function (or method) will contain no more than 200 logical source lines of code (L-SLOCs).
Samozřejmě to nelze považovat za dogma, tahle si to prostě nastavili. Nicméně je to asi přes limity tvého monitoru ;)
-
https://en.wikipedia.org/wiki/Cargo_cult_programming
"applying a design pattern or coding style blindly without understanding the reasons behind that design principle"
IMHO celkem sedí, viz fiasko s return ze switche
Zkus někdy jako referenční materiál použít něco jiného než Wikipedii. Ano, mají to tam blbě a také jsi to blbě pochopil.
Přečti si nejprve něco o skutečném kargo kultu a jeho letištích, proč to vzniklo a proč se jim piloti musí vyhýbat. Pak možná pochopíš, že v programování to znamená spoléhat se na "vyšší inteligenci", která nám přináší nové postupy, nové kompilátory, nové knihovny i nové frameworky. A když nám něco z toho nefunguje, tak se dovoláváme toho, aby to někdo spravil.
Jak vidíš, s VT100 to vůbec nesouvisí a s nějakým omezením 65 znaků/řádek, 20 řádek/funkci nebo 65 řádek/třídu také ne. Totéž s likvidací klíčových slov break i else. Prostě jsem si stanovil jasná, porušitelná, užitečná a pro mne krásná pravidla, která mi vyhovují. K nikomu se nemodlím, nikoho slepě nekopíruji. Není to tedy kargo kult.
-
Na svém LCD monitoru s rozlišením 1280×1024 vidím v editoru 40 řádek a na každém z nich 115 znaků. Když však kus programu pošlu do nějakého fóra, tak těch max 65 znaků na řádek je tak akorát na to, aby se vešel mezi ty pruhy reklam po stranách. Máš snad nějaký pádný důvod k tomu, aby ty řádky byly delší než 65 znaků? Dlouhé řádky mi prostě vadí při čtení - při jejich správném zalomení to vypadá mnohem lépe, lépe se mi s nimi pracuje a přitom mě nijak neomezují.
No tak to máš zastaralý monitor, dnes máme standard FullHD od $100 a mnoho programátorů má takové dva nebo jeden větší. Jednou za deset let se standard o něco zvětší, začínalo se na pouhých 640*480, možná i méně. Argument postování do fór je zcela mimo mísu. Zalomení na 65 nepřekvapivě způsobí menší přehlednost, způsobí zbytečnou nutnost scrolovat. Dle selského rozumu by dnes bylo zalamování někde na 150-200 znacích.
-
Jak vidíš, s VT100 to vůbec nesouvisí a s nějakým omezením 65 znaků/řádek, 20 řádek/funkci nebo 65 řádek/třídu také ne.
Limit 20 řádků zcela jasně pochází jako cargo cult z VT100, to jsme si tady dneska dokázali.
Odkud se vzalo číslo 65 ještě nevím, ale určitě to bude něco podobného.
-
Source lines will be kept to a length of 120 characters or less.
Any one function (or method) will contain no more than 200 logical source lines of code (L-SLOCs).
Samozřejmě to nelze považovat za dogma, tahle si to prostě nastavili. Nicméně je to asi přes limity tvého monitoru ;)
Tato pravidla mi nevyhovují, protože jsou příliš volná. Má vlastní pravidla jim vyhovují, proto nedělám žádnou chybu, když používám svá (mnohem přísnější) pravidla. Nedělám to z důvodu sebemrskačství, ale proto, abych se ve svých programech vyznal i po mnoha létech a nemusel v nich mít jediný komentář.
Takové stavební bloky se také mnohem snáze recyklují nebo sdílejí ve společných knihovnách. Samozřejmou podmínkou je dodržování OCP, jinak by se mi taková knihovna velmi brzy rozsypala.
U interpretovaných jazyků to přináší další podstatné výhody: 65řádkový modul je v PHP zkompilován mnohem rychleji než 500řádkový. Pokud má aplikace např. 10000 řádek a při každém webovém dotazu potřebuje výběr 5-10 takových modulů, je běh takové správně rozvrstvené aplikace mnohem rychlejší. A to si nevymýšlím, mám to změřeno na produkčních serverech.
PHP není pomalé, jsou jen nešikovní programátoři, kteří to s ním neumí a pletou si ho s C.
-
No tak to máš zastaralý monitor, dnes máme standard FullHD od $100 a mnoho programátorů má takové dva nebo jeden větší. Jednou za deset let se standard o něco zvětší, začínalo se na pouhých 640*480, možná i méně. Argument postování do fór je zcela mimo mísu. Zalomení na 65 nepřekvapivě způsobí menší přehlednost, způsobí zbytečnou nutnost scrolovat. Dle selského rozumu by dnes bylo zalamování někde na 150-200 znacích.
Nepotřebuji se při práci koukat na filmy. Kdybych měl FullHD, opět bych měl v editoru 40 řádek a asi 135 sloupců.
Jaké scrollování máš na mysli? Horizontální scrollování prostě nesnáším. Ani při zalamování příkazů na 65 znaků nemám bloky delší než ti, kteří zalamují až na 150. pozici. Na řádky to vychází nastejno, navíc ušetřím na šířku. Jsem na tom tedy mnohem lépe.
-
Odkud se vzalo číslo 65 ještě nevím, ale určitě to bude něco podobného.
To je z českých typografických norem, ale to asi také neznáš.
-
65 je normovaný počet úhozů na stránku u psacího stroje standardní velikost (ne perličky).
-
65 je normovaný počet úhozů na stránku u psacího stroje standardní velikost (ne perličky).
Používá tady snad někdo perličku? Já tedy ne. Na 19" monitoru se mi osvědčilo 14bodové písmo.