Fórum Root.cz
Hlavní témata => Vývoj => Téma založeno: Prog Ramator 10. 10. 2017, 15:04:52
-
Obcas mam chut v praci na spagety. Jaky je osvedceny recept?
Je rozdil v chuti pro programatory javy nebo. net?
Kteri z nich jsou vic zvykli na spageti code?
-
Ke špagetovému kódu vede používání else (ve smyslu řídící struktury) a víc než 4 úrovně zanoření zdrojového kódu. V tom si zmíněné jazyky nemají co vyčítat, záleží spíš na autorovi kódu.
Strukturované else je zcela postradatelnou komponentou - některé jazyky ji vůbec nemají a nechybí jim.
-
4 úrovně zanoření už obvykle bývá pěkně nepřehledná špageta... Nejlépe jen jedna, ale někdy jdou i dvě. Samozřejmě je pak potřeba používat víceslovné názvy metod a při rozdělování kódu do metod se hodí rozumné IDE...
-
Ke špagetovému kódu vede používání else (ve smyslu řídící struktury) a víc než 4 úrovně zanoření zdrojového kódu. V tom si zmíněné jazyky nemají co vyčítat, záleží spíš na autorovi kódu.
Strukturované else je zcela postradatelnou komponentou - některé jazyky ji vůbec nemají a nechybí jim.
Prave naopak. Viz jazyky, kde je if then else vyraz.
If bez else ma tendenci vest k tomu, ze kod pouziva sideeffecty.
-
Obcas mam chut v praci na spagety. Jaky je osvedceny recept?
https://cooking.nytimes.com/recipes/1017306-pasta-aglio-olio-e-peperoncino
-
Ke špagetovému kódu vede používání else (ve smyslu řídící struktury) a víc než 4 úrovně zanoření zdrojového kódu. V tom si zmíněné jazyky nemají co vyčítat, záleží spíš na autorovi kódu.
Strukturované else je zcela postradatelnou komponentou - některé jazyky ji vůbec nemají a nechybí jim.
Prave naopak. Viz jazyky, kde je if then else vyraz.
If bez else ma tendenci vest k tomu, ze kod pouziva sideeffecty.
Proto jsem psal "strukturované else", aby zase nějaký chytrák nevyrukoval s else, které je součástí výrazu.
-
Moje recepty pre javu:
1. pisat v jave, ako keby to bol proceduralny turbo pascal a vsetko public static
2. spravit architekturu aplikacie a potom si zmysliet idiotske featury, co to cele rozbiju
3. pokusat sa spravit aplikaciu rock solid, aby spracovala kazdy vstup bez ohladu na to, aky je zmrdany, miesto toho, aby sa zmrdany vstup hned na zaciatku odmietol.
4. Copy paste koderina, a pokusit sa nacpat vsetko do jednej metody, nech ma aspon 300 riadkov a viac. Co na tom, ze sa kod opakuje ...
5. Hashmap je univerzalny datovy typ, vsade pouzijes hashmap a mas vystarane
-
Ke špagetovému kódu vede používání else (ve smyslu řídící struktury) a víc než 4 úrovně zanoření zdrojového kódu. V tom si zmíněné jazyky nemají co vyčítat, záleží spíš na autorovi kódu.
Strukturované else je zcela postradatelnou komponentou - některé jazyky ji vůbec nemají a nechybí jim.
Prave naopak. Viz jazyky, kde je if then else vyraz.
If bez else ma tendenci vest k tomu, ze kod pouziva sideeffecty.
Proto jsem psal "strukturované else", aby zase nějaký chytrák nevyrukoval s else, které je součástí výrazu.
Tak si nejdriv ujasni pojmy. I else jako soucast vyrazu je "strukturovane".
-
Ke špagetovému kódu vede používání else (ve smyslu řídící struktury) a víc než 4 úrovně zanoření zdrojového kódu. V tom si zmíněné jazyky nemají co vyčítat, záleží spíš na autorovi kódu.
Strukturované else je zcela postradatelnou komponentou - některé jazyky ji vůbec nemají a nechybí jim.
Prave naopak. Viz jazyky, kde je if then else vyraz.
If bez else ma tendenci vest k tomu, ze kod pouziva sideeffecty.
Proto jsem psal "strukturované else", aby zase nějaký chytrák nevyrukoval s else, které je součástí výrazu.
Tak si nejdriv ujasni pojmy. I else jako soucast vyrazu je "strukturovane".
Else, které je součástí řídicích struktur.
V ternárních operátorech Java ani C# nepoužívají else, ale dvojtečku.
Musíš do toho pokaždé vrtat jako nějaký troll? Ostatní už dávno vědí, o co se jedná, tak ze sebe nedělej hnidopicha.
-
Tak jeste jinak:
if (a) {
x = y;
}
je nejspis problem.
Obdoby
if (a) {
return foo;
} else {
return bar;
}
maji vetsi sanci byt OK.
To neni o nejakych otazniccich vs klicovych slovech ale o vysledne semantice a sideefectech. A je to jinak, nez pises - prave absence else je jedno z mnoha varovani.
-
takze ako nahradit napr. 4 vnorene ify?
-
takze ako nahradit napr. 4 vnorene ify?
Záleží na okolnostech. Často je řešení refaktoring, kdy vnitřky extrahuješ do samostatných (obvykle privátních) metod. Což tě donutí je pojmenovat. A to tě zase donutí těm kusům případně nějaký jasný význam.
-
takze ako nahradit napr. 4 vnorene ify?
Nevnořovat je, ale dát je pod sebe, každý zvlášť. Uvnitř každé z nich mít throw nebo return. Podmínky je obvykle je nutné negovat. Teprve pokud není splněna žádná podmínka, provede se výkonná část kódu, která se nachází až za nimi.
https://wpshout.com/unconditionally-refactoring-nested-statements-cleaner-code/ (https://wpshout.com/unconditionally-refactoring-nested-statements-cleaner-code/)
https://softwareengineering.stackexchange.com/questions/206816/clarification-of-avoid-if-else-advice (https://softwareengineering.stackexchange.com/questions/206816/clarification-of-avoid-if-else-advice)
https://www.youtube.com/watch?v=kisKOhifiC0 (https://www.youtube.com/watch?v=kisKOhifiC0)
-
Ke špagetovému kódu vede používání else (ve smyslu řídící struktury) a víc než 4 úrovně zanoření zdrojového kódu. V tom si zmíněné jazyky nemají co vyčítat, záleží spíš na autorovi kódu.
Strukturované else je zcela postradatelnou komponentou - některé jazyky ji vůbec nemají a nechybí jim.
Prave naopak. Viz jazyky, kde je if then else vyraz.
If bez else ma tendenci vest k tomu, ze kod pouziva sideeffecty.
Souhlas. Obecne naduzivani ifu byva znamka programu lepeneho bez rozmyslu.
-
Obcas mam chut v praci na spagety. Jaky je osvedceny recept?
https://cooking.nytimes.com/recipes/1017306-pasta-aglio-olio-e-peperoncino
Boloňský taky dobrý, samozřejmě - udělaný doma, ne upatlaný z polotovaru. A když je sezona, tak spaghetti pomodoro, jednoduchý jak cvičky a naprosto luxusní. Obé kompatibilní s Javou i .NETem ;D
-
takze ako nahradit napr. 4 vnorene ify?
Nevnořovat je, ale dát je pod sebe, každý zvlášť. Uvnitř každé z nich mít throw nebo return. Podmínky je obvykle je nutné negovat. Teprve pokud není splněna žádná podmínka, provede se výkonná část kódu, která se nachází až za nimi.
https://wpshout.com/unconditionally-refactoring-nested-statements-cleaner-code/ (https://wpshout.com/unconditionally-refactoring-nested-statements-cleaner-code/)
https://softwareengineering.stackexchange.com/questions/206816/clarification-of-avoid-if-else-advice (https://softwareengineering.stackexchange.com/questions/206816/clarification-of-avoid-if-else-advice)
https://www.youtube.com/watch?v=kisKOhifiC0 (https://www.youtube.com/watch?v=kisKOhifiC0)
Asi otazka vkusu treba podle Petera Norviga je vice returnu v jedne funkci spatne. Jeho tutorial on good programming style je jeden z mala textu na tohle tema, ktery jsem cetl a dava mi smysl.
-
Ha, ha, ha, ... Žádné vnořené ify mi při programování nevznikají, prý se to jmenuje gateway style :-)))
například:
def extract(name):
def _find(result, n):
if name in columns[n].options:
result.append((n, columns[n].options[name].split(':')))
return result
return _find
for name, field in reduce(extract('source'), iter(columns), []):
pass
for name, field in reduce(extract('rowid'), iter(columns), []):
if field == ['']:
pass
else:
pass
-
Obcas mam chut v praci na spagety. Jaky je osvedceny recept?
https://cooking.nytimes.com/recipes/1017306-pasta-aglio-olio-e-peperoncino
Boloňský taky dobrý, samozřejmě - udělaný doma, ne upatlaný z polotovaru. A když je sezona, tak spaghetti pomodoro, jednoduchý jak cvičky a naprosto luxusní. Obé kompatibilní s Javou i .NETem ;D
To ja radsej pouzivam susene spagety, ono vytahovat to z cesta je dost otrava, najma ked clovek nema skill.
-
Záleží na okolnostech. Často je řešení refaktoring, kdy vnitřky extrahuješ do samostatných (obvykle privátních) metod. Což tě donutí je pojmenovat. A to tě zase donutí těm kusům případně nějaký jasný význam.
Takze mas na mysli to, ze 4 ify ostanu vnorene, ale logiku z jednotlivych ifov presunies do metod?
-
Záleží na okolnostech. Často je řešení refaktoring, kdy vnitřky extrahuješ do samostatných (obvykle privátních) metod. Což tě donutí je pojmenovat. A to tě zase donutí těm kusům případně nějaký jasný význam.
Takze mas na mysli to, ze 4 ify ostanu vnorene, ale logiku z jednotlivych ifov presunies do metod?
Sorry, ze sa vam miesam, ale osobne, ked nieco zrefactorujem do metod, potom sa mi ten les if-ov aj lepsie prehodi na plain strukturu. Lebo s izolovanymi metodami, kde su nejake vstupy a nejake vystupy (testovatelne) sa lahsie pracuje nez s "kusmi kodu", ktore robia neurcitu cinnost.
-
Ha, ha, ha, ... Žádné vnořené ify mi při programování nevznikají, prý se to jmenuje gateway style :-)))
například:
def extract(name):
def _find(result, n):
if name in columns[n].options:
result.append((n, columns[n].options[name].split(':')))
return result
return _find
for name, field in reduce(extract('source'), iter(columns), []):
pass
for name, field in reduce(extract('rowid'), iter(columns), []):
if field == ['']:
pass
else:
pass
je to pěkné. možná by bylo jednodušší použít sum(map(...), []). Nemusel byste apendovat. To vaše je asi obecnější a něco mi uniká.
-
Přesně tak. Metody mají pořádné pojmenování, jejich lokální proměnné se nemíchají do ostatních (klasické zneužívání již nadefinovaných proměnných v různých částech kódu, kolik chyb už to způsobilo...), jednotlivé vrstvy abstrakce se od sebe krásně oddělí a zpřehlední, zpracování stejného z různých částí algoritmu řeší jen jeden kód v metodě. Základní jednoduché věci, ale bohužel stále ne vývojářský standard... Učí se to vůbec na školách?
Často člověk při takovém refaktoringu narazí i na logickou chybu, kterou v původních 4-úrovňových špagetách nebylo vidět.
-
Přesně tak. Metody mají pořádné pojmenování, jejich lokální proměnné se nemíchají do ostatních (klasické zneužívání již nadefinovaných proměnných v různých částech kódu, kolik chyb už to způsobilo...), jednotlivé vrstvy abstrakce se od sebe krásně oddělí a zpřehlední, zpracování stejného z různých částí algoritmu řeší jen jeden kód v metodě. Základní jednoduché věci, ale bohužel stále ne vývojářský standard... Učí se to vůbec na školách?
Často člověk při takovém refaktoringu narazí i na logickou chybu, kterou v původních 4-úrovňových špagetách nebylo vidět.
Když se me takový kéd dostane pod ruku, dokážu ho zkrátit na cca 10-20% původní délky zrušením abstrakcí a zredukováním na jednu vrstvu. Dost mi to zjednodušší budoucí údržbu.
-
Přesně tak. Metody mají pořádné pojmenování, jejich lokální proměnné se nemíchají do ostatních (klasické zneužívání již nadefinovaných proměnných v různých částech kódu, kolik chyb už to způsobilo...), jednotlivé vrstvy abstrakce se od sebe krásně oddělí a zpřehlední, zpracování stejného z různých částí algoritmu řeší jen jeden kód v metodě. Základní jednoduché věci, ale bohužel stále ne vývojářský standard... Učí se to vůbec na školách?
Často člověk při takovém refaktoringu narazí i na logickou chybu, kterou v původních 4-úrovňových špagetách nebylo vidět.
Když se mi takový kód dostane pod ruku, dokážu ho zkrátit na cca 10-20% původní délky zrušením abstrakcí a zredukováním na jednu vrstvu. Dost mi to zjednodušší budoucí údržbu.
oprava: me -> mi, kéd -> kód
-
Přesně tak. Metody mají pořádné pojmenování, jejich lokální proměnné se nemíchají do ostatních (klasické zneužívání již nadefinovaných proměnných v různých částech kódu, kolik chyb už to způsobilo...), jednotlivé vrstvy abstrakce se od sebe krásně oddělí a zpřehlední, zpracování stejného z různých částí algoritmu řeší jen jeden kód v metodě. Základní jednoduché věci, ale bohužel stále ne vývojářský standard... Učí se to vůbec na školách?
Často člověk při takovém refaktoringu narazí i na logickou chybu, kterou v původních 4-úrovňových špagetách nebylo vidět.
Když se me takový kéd dostane pod ruku, dokážu ho zkrátit na cca 10-20% původní délky zrušením abstrakcí a zredukováním na jednu vrstvu. Dost mi to zjednodušší budoucí údržbu.
Ostatne proc by mely mit veci vhodna jmena, coz?
-
Přesně tak. Metody mají pořádné pojmenování, jejich lokální proměnné se nemíchají do ostatních (klasické zneužívání již nadefinovaných proměnných v různých částech kódu, kolik chyb už to způsobilo...), jednotlivé vrstvy abstrakce se od sebe krásně oddělí a zpřehlední, zpracování stejného z různých částí algoritmu řeší jen jeden kód v metodě. Základní jednoduché věci, ale bohužel stále ne vývojářský standard... Učí se to vůbec na školách?
Často člověk při takovém refaktoringu narazí i na logickou chybu, kterou v původních 4-úrovňových špagetách nebylo vidět.
Když se me takový kéd dostane pod ruku, dokážu ho zkrátit na cca 10-20% původní délky zrušením abstrakcí a zredukováním na jednu vrstvu. Dost mi to zjednodušší budoucí údržbu.
Ostatne proc by mely mit veci vhodna jmena, coz?
vhodná jména jsou krátká. Stačí nepoužívat hvězdičkové importy. Nemusí mít každá věc unikátní jméno.
-
Přesně tak. Metody mají pořádné pojmenování, jejich lokální proměnné se nemíchají do ostatních (klasické zneužívání již nadefinovaných proměnných v různých částech kódu, kolik chyb už to způsobilo...), jednotlivé vrstvy abstrakce se od sebe krásně oddělí a zpřehlední, zpracování stejného z různých částí algoritmu řeší jen jeden kód v metodě. Základní jednoduché věci, ale bohužel stále ne vývojářský standard... Učí se to vůbec na školách?
Často člověk při takovém refaktoringu narazí i na logickou chybu, kterou v původních 4-úrovňových špagetách nebylo vidět.
Když se me takový kéd dostane pod ruku, dokážu ho zkrátit na cca 10-20% původní délky zrušením abstrakcí a zredukováním na jednu vrstvu. Dost mi to zjednodušší budoucí údržbu.
Pravděpodobně máte na mysli neustálé přepisování většiny z těch zbylých 10-20% při jakkoliv malé změně a úplné otestování celé aplikace, protože vlivem absence jakýchkoliv logických celků (abstrakcí) není automatický dílčí test možný.
-
Vhodná jména jsou taková, která správně popisují, co daná metoda dělá. Samozřejmě co nejkratším způsobem, ale dostatečně.
Kód se má číst jako anglický příběh. Vychytávky a nečitelné optimalizace jsou fajn pro ego jejich autora, ale ne pro zdravý rozum jeho následovníků a dlouhodobou efektivitu investice majitele kódu.
-
Přesně tak. Metody mají pořádné pojmenování, jejich lokální proměnné se nemíchají do ostatních (klasické zneužívání již nadefinovaných proměnných v různých částech kódu, kolik chyb už to způsobilo...), jednotlivé vrstvy abstrakce se od sebe krásně oddělí a zpřehlední, zpracování stejného z různých částí algoritmu řeší jen jeden kód v metodě. Základní jednoduché věci, ale bohužel stále ne vývojářský standard... Učí se to vůbec na školách?
Často člověk při takovém refaktoringu narazí i na logickou chybu, kterou v původních 4-úrovňových špagetách nebylo vidět.
Když se me takový kéd dostane pod ruku, dokážu ho zkrátit na cca 10-20% původní délky zrušením abstrakcí a zredukováním na jednu vrstvu. Dost mi to zjednodušší budoucí údržbu.
Ostatne proc by mely mit veci vhodna jmena, coz?
vhodná jména jsou krátká. Stačí nepoužívat hvězdičkové importy. Nemusí mít každá věc unikátní jméno.
Importy s tim nesouviseji. Minimalne na zacatku ten refaktoring povede na (typicky private nebo package private) metody ve stejne tride.
-
Přesně tak. Metody mají pořádné pojmenování, jejich lokální proměnné se nemíchají do ostatních (klasické zneužívání již nadefinovaných proměnných v různých částech kódu, kolik chyb už to způsobilo...), jednotlivé vrstvy abstrakce se od sebe krásně oddělí a zpřehlední, zpracování stejného z různých částí algoritmu řeší jen jeden kód v metodě. Základní jednoduché věci, ale bohužel stále ne vývojářský standard... Učí se to vůbec na školách?
Často člověk při takovém refaktoringu narazí i na logickou chybu, kterou v původních 4-úrovňových špagetách nebylo vidět.
Když se me takový kéd dostane pod ruku, dokážu ho zkrátit na cca 10-20% původní délky zrušením abstrakcí a zredukováním na jednu vrstvu. Dost mi to zjednodušší budoucí údržbu.
Pravděpodobně máte na mysli neustálé přepisování většiny z těch zbylých 10-20% při jakkoliv malé změně a úplné otestování celé aplikace, protože vlivem absence jakýchkoliv logických celků (abstrakcí) není automatický dílčí test možný.
Ani bych neřekl. Ony ty abstrakce často nic nedělají. Typický případ je obalování nějakého modulu třetí strany vlastním API.
Abstrakce mají smysl až tam, kde se opakuje nějaký vzor. Často narážím na abstrakce, které jsou použity pouze jednou. To je plýtvání úsilím hlavně čtenářů toho kódu.
-
Abstrakce mají smysl až tam, kde se opakuje nějaký vzor. Často narážím na abstrakce, které jsou použity pouze jednou. To je plýtvání úsilím hlavně čtenářů toho kódu.
Zdaleka ne nutne. Pokud neco schovavaji pod dobrym jmenem, tak zjednodusi cteni tim, ze dotycneho odstini od detailu, ktere v dany okamzik nepotrebuje.
Vseho primerene, samozrejme.
-
Tahle to beru, ovšem z původní odpovědi mi to nějak nevyplývalo...
-
Vhodná jména jsou taková, která správně popisují, co daná metoda dělá. Samozřejmě co nejkratším způsobem, ale dostatečně.
Kód se má číst jako anglický příběh. Vychytávky a nečitelné optimalizace jsou fajn pro ego jejich autora, ale ne pro zdravý rozum jeho následovníků a dlouhodobou efektivitu investice majitele kódu.
Ego se dá honit i na abstrakcích a natahování kódu. Je otázka, kdo nadělá víc škody.
-
Škodu nadělá ten, kdo zhorší čitelnost kódu pro ostatní. Ať už jakýmkoliv způsobem. Čitelnost kódu má po každé úpravě minimálně zůstat, spíše se zlepšit. Není to žádná teorie, všichni vývojáři s tím bojují každý den.
-
Škodu nadělá ten, kdo zhorší čitelnost kódu pro ostatní. Ať už jakýmkoliv způsobem. Čitelnost kódu má po každé úpravě minimálně zůstat, spíše se zlepšit. Není to žádná teorie, všichni vývojáři s tím bojují každý den.
Čitelnost je subjektivní metrika. Proto existují různé style guides, aby se lidé nemuseli hádat co je a co není čitelné. Lze automaticky kontrolovat i názvy proměnných, aby splňovaly určitá pravidla.
Délka kódu je objektivní metrika. Kratší kód by měl dostat přednost.
-
Vhodná jména jsou taková, která správně popisují, co daná metoda dělá. Samozřejmě co nejkratším způsobem, ale dostatečně.
Kód se má číst jako anglický příběh. Vychytávky a nečitelné optimalizace jsou fajn pro ego jejich autora, ale ne pro zdravý rozum jeho následovníků a dlouhodobou efektivitu investice majitele kódu.
Ego se dá honit i na abstrakcích a natahování kódu. Je otázka, kdo nadělá víc škody.
To se nedělá kvůli egu, ale protože po tobě může udržovat kód chlápek s motorovou pilou, co si zjistí tvou adresu...
Udělat kód co nejcitelnější je téměř vždy základní ohleduplnost k okolí.
-
Škodu nadělá ten, kdo zhorší čitelnost kódu pro ostatní. Ať už jakýmkoliv způsobem. Čitelnost kódu má po každé úpravě minimálně zůstat, spíše se zlepšit. Není to žádná teorie, všichni vývojáři s tím bojují každý den.
Čitelnost je subjektivní metrika. Proto existují různé style guides, aby se lidé nemuseli hádat co je a co není čitelné. Lze automaticky kontrolovat i názvy proměnných, aby splňovaly určitá pravidla.
Délka kódu je objektivní metrika. Kratší kód by měl dostat přednost.
Že je něco objektivní znamená, že to umíš měřit. Ne že je to důležitější. (Tohle je jeden z nejtypičtějších omylů vůbec.)
-
Délka kódu je objektivní metrika. Kratší kód by měl dostat přednost.
V žádném případě s takovým zjednodušením nesouhlasím.
-
Délka kódu je objektivní metrika. Kratší kód by měl dostat přednost.
V žádném případě s takovým zjednodušením nesouhlasím.
Jasně, je to zjednodušující, ale většinou to platí. Zbytečně dlouhý kód je IMHO častější problém. Upřednostňování kratšího kódu doporučuje většina autorů různých style guidů.
Maximize LOCNW lines of code not written.
Shorter is better and shortest is best.
-- Jim Meehan
https://www.cs.umd.edu/~nau/cmsc421/norvig-lisp-style.pdf
-
vhodná jména jsou krátká. Stačí nepoužívat hvězdičkové importy. Nemusí mít každá věc unikátní jméno.
Vhodné jméno se musí brát včetně kompletního namespace. Pokud obsahuje pleonasmy, je to špatně a je to zdrojem budoucích problémů. Hvězdičkové importy už snad moderní IDE nedělají. Java bohužel neumí aliasy v importech, což občas svádí k těm nežádoucím unikátním názvům tříd.
-
Zbytečně dlouhý kód je IMHO častější problém. Upřednostňování kratšího kódu ...
Taky nemluvím o zbytečně dlouhém kódu, ale o přehledném. A ten se určitě nedosáhne minimalizací LOC. Příklad - ve wicketu (ale i pythonovském remi) bývá v konstruktorech komponent hodně dlouhá lineární sekvence vytváření a přidávání subkomponent. Jednotlivé subkomponenty mívají více řádků kódu, často jich několik spolu úzce souvisí. Když takový lineární kód nerozsekám do řady vhodně pojmenovaných metod, je z toho dlouhá nepřehledná špageta. Více LOC.
Někdy i pouhé vytvoření a úvodní nastavení proměnné, které by šlo vyřešit jednořádkovým ternárním operátorem, strčím do extra metody s if/else, když potřebuji okomentovat důvody jednotlivých variant a na první pohled nejsou zřejmé. Opět více LOC. Občas se hodí strčit do vhodně pojmenované metody i jeden řádek, než jej v toku kódu popisovat komentářem. Často právě takové krátké metody bývají vhodnými kandidáty na přetížení potomky, až za pár měsíců přijdou další požadavky vzniklé na základě praktického používání stávající funkčnosti. Protože ty metodky řeší právě jednu věc, kterou je požadavek v potomkovi rozšířit. Každá metoda volaná jen z jednoho místa logicky prodlužuje kód. Jenže má jasně viditelné a dané vstupy a jasný výstup, narozdíl od bloku kódu špagety, ze kterého pochází.
K tomu je ale potřeba pořádný editor, který umí metody včetně typů a vhodných názvů vytahovat na jednu klávesovou zkratku, a ne to dělat cut/paste...
Takových případů se najde mraky. Je to o čitelnosti a snadnosti pochopení, ne o celkové délce.
-
Zbytečně dlouhý kód je IMHO častější problém. Upřednostňování kratšího kódu ...
Taky nemluvím o zbytečně dlouhém kódu, ale o přehledném. A ten se určitě nedosáhne minimalizací LOC. Příklad - ve wicketu (ale i pythonovském remi) bývá v konstruktorech komponent hodně dlouhá lineární sekvence vytváření a přidávání subkomponent. Jednotlivé subkomponenty mívají více řádků kódu, často jich několik spolu úzce souvisí. Když takový lineární kód nerozsekám do řady vhodně pojmenovaných metod, je z toho dlouhá nepřehledná špageta. Více LOC.
Někdy i pouhé vytvoření a úvodní nastavení proměnné, které by šlo vyřešit jednořádkovým ternárním operátorem, strčím do extra metody s if/else, když potřebuji okomentovat důvody jednotlivých variant a na první pohled nejsou zřejmé. Opět více LOC. Občas se hodí strčit do vhodně pojmenované metody i jeden řádek, než jej v toku kódu popisovat komentářem. Často právě takové krátké metody bývají vhodnými kandidáty na přetížení potomky, až za pár měsíců přijdou další požadavky vzniklé na základě praktického používání stávající funkčnosti. Protože ty metodky řeší právě jednu věc, kterou je požadavek v potomkovi rozšířit. Každá metoda volaná jen z jednoho místa logicky prodlužuje kód. Jenže má jasně viditelné a dané vstupy a jasný výstup, narozdíl od bloku kódu špagety, ze kterého pochází.
K tomu je ale potřeba pořádný editor, který umí metody včetně typů a vhodných názvů vytahovat na jednu klávesovou zkratku, a ne to dělat cut/paste...
Takových případů se najde mraky. Je to o čitelnosti a snadnosti pochopení, ne o celkové délce.
Pokud dodržíš kritéria, která jsi napsal, zpravidla obdržíš kód, který je nejen čitelnější, ale i kratší.
Jednoduchým ukazatelem, ve kterých místech provést uvedené refaktorování, jsou prázdné řádky uvnitř metod. Zpravidla oddělují funkčí celky, které by měly být v samostatných metodách, nezřídka i v jiných třídách.
-
Zbytečně dlouhý kód je IMHO častější problém. Upřednostňování kratšího kódu ...
Taky nemluvím o zbytečně dlouhém kódu, ale o přehledném. A ten se určitě nedosáhne minimalizací LOC. Příklad - ve wicketu (ale i pythonovském remi) bývá v konstruktorech komponent hodně dlouhá lineární sekvence vytváření a přidávání subkomponent. Jednotlivé subkomponenty mívají více řádků kódu, často jich několik spolu úzce souvisí. Když takový lineární kód nerozsekám do řady vhodně pojmenovaných metod, je z toho dlouhá nepřehledná špageta. Více LOC.
Někdy i pouhé vytvoření a úvodní nastavení proměnné, které by šlo vyřešit jednořádkovým ternárním operátorem, strčím do extra metody s if/else, když potřebuji okomentovat důvody jednotlivých variant a na první pohled nejsou zřejmé. Opět více LOC. Občas se hodí strčit do vhodně pojmenované metody i jeden řádek, než jej v toku kódu popisovat komentářem. Často právě takové krátké metody bývají vhodnými kandidáty na přetížení potomky, až za pár měsíců přijdou další požadavky vzniklé na základě praktického používání stávající funkčnosti. Protože ty metodky řeší právě jednu věc, kterou je požadavek v potomkovi rozšířit. Každá metoda volaná jen z jednoho místa logicky prodlužuje kód. Jenže má jasně viditelné a dané vstupy a jasný výstup, narozdíl od bloku kódu špagety, ze kterého pochází.
K tomu je ale potřeba pořádný editor, který umí metody včetně typů a vhodných názvů vytahovat na jednu klávesovou zkratku, a ne to dělat cut/paste...
Takových případů se najde mraky. Je to o čitelnosti a snadnosti pochopení, ne o celkové délce.
Jasně, že se to nesmí brát doslovně. Proti krátkým funkcím/metodám nikdo nic nemá. Pokud něco opravdu dělají. Pokud se přidávají jen jako mezivrstva pro volání jiných funkcí, je to IMHO špatně.
-
Nemusí dělat nic jiného, než že jen rozdělují kód do logicky souvisejících bloků a nějak je výstižně pojmenovávají (obvykle jedno slovo nestačí). I takové metody mají pro čitelnost a přehlednost význam.
-
Nemusí dělat nic jiného, než že jen rozdělují kód do logicky souvisejících bloků a nějak je výstižně pojmenovávají (obvykle jedno slovo nestačí). I takové metody mají pro čitelnost a přehlednost význam.
Pokud nestačí jedno slovo v názvu metody, tak stojí za zvážení, zda třída splňuje SRP a zda není vhodné ji rozdělit.
-
Metoda něco dělá, takže minimálně sloveso (co dělá, přísudek) a téměř vždy k tomu nějaké podstatné jméno "čemu" (předmět). Často ještě upřesněné přídavným jménem. Nedovedu si představit, jak metody obsahující např. inicializaci konkrétních bloků subkomponent nějaké hlavní komponenty (můj příklad rozpadu dlouhého lineárního kódu) mohou mít jednoslovný název.
Tvé jednoslovné názvy by mě opravdu zajímaly. Buď máš vše do posledního detailu rozdělené do minimalistických tříd s pár metodami (čemuž nevěřím), nebo jsou názvy nedostatečně popisné a anglicky nesrozumitelné. Protože jednoslovné metody by znamenaly, že tím předmětem je implicitní "itself" - load itself, store itself, initialize itself, atd. Ukaž nějaký kód, ale to už tě tu žádalo spoustu lidí.
-
Metoda něco dělá, takže minimálně sloveso (co dělá, přísudek) a téměř vždy k tomu nějaké podstatné jméno "čemu" (předmět). Často ještě upřesněné přídavným jménem. Nedovedu si představit, jak metody obsahující např. inicializaci konkrétních bloků subkomponent nějaké hlavní komponenty (můj příklad rozpadu dlouhého lineárního kódu) mohou mít jednoslovný název.
Tvé jednoslovné názvy by mě opravdu zajímaly. Buď máš vše do posledního detailu rozdělené do minimalistických tříd s pár metodami (čemuž nevěřím), nebo jsou názvy nedostatečně popisné a anglicky nesrozumitelné. Protože jednoslovné metody by znamenaly, že tím předmětem je implicitní "itself" - load itself, store itself, initialize itself, atd. Ukaž nějaký kód, ale to už tě tu žádalo spoustu lidí.
Konvence jsou v kazdem jazyku jine. Nebyva uplne spatny napad se nejdriv podivat na konvence pouzivane ve standartni knihovne, pripadne si zapnout nejakou kontrolu stylu.
namatkou metody vestavenych typu Pythonu
list
list.append list.clear list.copy list.count list.extend list.index
list.insert list.mro list.pop list.remove list.reverse list.sort
str
str.capitalize str.casefold str.center str.count str.encode str.endswith str.expandtabs str.find str.format
str.format_map str.index str.isalnum str.isalpha str.isdecimal str.isdigit str.isidentifier str.islower str.isnumeric
str.isprintable str.isspace str.istitle str.isupper str.join str.ljust str.lower str.lstrip str.maketrans
str.mro str.partition str.replace str.rfind str.rindex str.rjust str.rpartition str.rsplit str.rstrip
str.split str.splitlines str.startswith str.strip str.swapcase str.title str.translate str.upper str.zfill
dict
dict.clear dict.copy dict.fromkeys dict.get dict.items dict.keys
dict.mro dict.pop dict.popitem dict.setdefault dict.update dict.values
soubor
f.buffer f.close f.closed f.detach f.encoding f.errors f.fileno f.flush f.isatty
f.line_buffering f.mode f.name f.newlines f.read f.readable f.readline f.readlines f.seek
f.seekable f.tell f.truncate f.writable f.write f.writelines
moc dvouslovnych nazvu tam nevidim.
-
Metoda něco dělá, takže minimálně sloveso (co dělá, přísudek) a téměř vždy k tomu nějaké podstatné jméno "čemu" (předmět). Často ještě upřesněné přídavným jménem. Nedovedu si představit, jak metody obsahující např. inicializaci konkrétních bloků subkomponent nějaké hlavní komponenty (můj příklad rozpadu dlouhého lineárního kódu) mohou mít jednoslovný název.
Tvé jednoslovné názvy by mě opravdu zajímaly. Buď máš vše do posledního detailu rozdělené do minimalistických tříd s pár metodami (čemuž nevěřím), nebo jsou názvy nedostatečně popisné a anglicky nesrozumitelné. Protože jednoslovné metody by znamenaly, že tím předmětem je implicitní "itself" - load itself, store itself, initialize itself, atd. Ukaž nějaký kód, ale to už tě tu žádalo spoustu lidí.
Ano, dělám minimalistické třídy, většinou na 20-80 řádek. Tím předmětem je skutečně "itself". Místo load() mám konstruktor, ve kterém by mohlo být i initialize(), ale netuším k čemu by bylo dobré. Co by mělo dělat store()? Pro přidávání položek kolekce používám spíš add(), pro hledání find(), pro změnu dat update(), pro prezentaci implicitní metody __toString() nebo třeba jsonSerialize(). Ty jsou sice ze dvou slov, ale s tím nic neudělám. Aspoň snadno poznám, že jsem jejich názvy nevymýšlel.
Inicializaci konkrétních bloků subkomponent dělám v konstruktorech dalších objektů, které následně injektuji do konstruktoru objektu, ve kterém bys měl tohle vše naházeno. Objekty dělím na procesní (drží si jen informace o vlastní konfiguraci a metodice výpočtu, nikoli však data) a datové, které bývají uspořádány do kolekce, např. stromu.
-
namatkou metody vestavenych typu Pythonu
...
moc dvouslovnych nazvu tam nevidim.
Moc hezký výčet. Kéž by sloužil i ostatním pro inspiraci.
-
namatkou metody vestavenych typu Pythonu
...
moc dvouslovnych nazvu tam nevidim.
Moc hezký výčet. Kéž by sloužil i ostatním pro inspiraci.
Ostatni by se meli inspirovat v jazyku/frameworku, ktery pouzivaji.
-
Ukažte kód, kde mají vaše komponenty řešící něco konkrétního názvy stejně obecné, jako zde ukázané názvy ve standardních knihovnách obecných prvků (list, string, dictionary). A to hodně přes polovinu je dvouslovné. Jakmile do toho zavedete doménové termíny ("byznys model"), musíte popisovat něco konkrétního. Nebo žádný kód nemáte a jenom tu popisujete teorii?
-
Ukažte kód, kde mají vaše komponenty řešící něco konkrétního názvy stejně obecné, jako zde ukázané názvy ve standardních knihovnách obecných prvků (list, string, dictionary). A to hodně přes polovinu je dvouslovné. Jakmile do toho zavedete doménové termíny ("byznys model"), musíte popisovat něco konkrétního. Nebo žádný kód nemáte a jenom tu popisujete teorii?
Na rozlišení domén přece slouží namespace.
-
Ukaž reálný kód, kde máš vše rozpadlé do tolika tříd, že si vystačíš s jednoslovnými metodami, tj. v podstatě pouze slovesy. Pořád nevím, o čem tu mluvíš.
-
Ukažte kód, kde mají vaše komponenty řešící něco konkrétního názvy stejně obecné, jako zde ukázané názvy ve standardních knihovnách obecných prvků (list, string, dictionary). A to hodně přes polovinu je dvouslovné. Jakmile do toho zavedete doménové termíny ("byznys model"), musíte popisovat něco konkrétního. Nebo žádný kód nemáte a jenom tu popisujete teorii?
Ja tu diskutuji anonymne. Nevim co je teoretickeho na vestavenych typech/funkcich. Tezko najit v praxi pouzivanejsi vec. Teorii tu nepopisuji, naopak, ja jsem v techto diskuzich jediny praktik. Casto sem posilam reseni ve forme funkcniho kodu.
-
Sorry, mě nezajímá teorie. Zajímá mě (a věřím, že i spoustu ostatních), jak vypadá kód, který skutečně něco reálného řeší a používá jen jednoslovné metody. Já takový neznám. Nejsou jimi ani ty základní třídy, které samy o sobě žádný reálný problém neřeší a přesto mají minimálně polovinu dvouslovných metod (pro boolean isXXX, vrací getXXX, setXXX, right trim rtrim, left trim ltrim, zero fill zfill atd. - viz API pro string.
-
Sorry, mě nezajímá teorie. Zajímá mě (a věřím, že i spoustu ostatních), jak vypadá kód, který skutečně něco reálného řeší a používá jen jednoslovné metody. Já takový neznám. Nejsou jimi ani ty základní třídy, které samy o sobě žádný reálný problém neřeší a přesto mají minimálně polovinu dvouslovných metod (pro boolean isXXX, vrací getXXX, setXXX, right trim rtrim, left trim ltrim, zero fill zfill atd. - viz API pro string.
setXXX, getXXX se v pythonu nepoužívá. Zaprve je to cammelcase a zadruhe k tomu ucelu slouzi properties. Kdyz uz chcete pouzit metodu, tak podstatne jmeno nebo sloveso v trpnem rode namisto getxxx. Sloveso v cinnem rode misto setxx. Je to konvence bezna ve vsech novejsich knihovnach. rtrim beru jako jedno slovo - zkratku.
-
Sorry, mě nezajímá teorie. Zajímá mě (a věřím, že i spoustu ostatních), jak vypadá kód, který skutečně něco reálného řeší a používá jen jednoslovné metody. Já takový neznám. Nejsou jimi ani ty základní třídy, které samy o sobě žádný reálný problém neřeší a přesto mají minimálně polovinu dvouslovných metod (pro boolean isXXX, vrací getXXX, setXXX, right trim rtrim, left trim ltrim, zero fill zfill atd. - viz API pro string.
Základní třídy jsou obvykle příliš obecné, proto mají mnoho metod, z nichž většinu nepotřebujeme. Není tedy vhodné je brát jako vzor, protože u vlastních tříd nám obvykle stačí 3-5 veřejných metod. Pokud ty metody pojmenuješ sémanticky, tak ti to jedno slovo obvykle stačí. Zejména pokud chceš uplatnit polymorfismus, u kterého název metody musíš oddělit od souvislosti s názvem třídy objektu i jeho atributů. Není zde tedy prostor pro názvy isXXX, getXXX, setXXX apod, neboť objekt má skrývat svou implementaci. Jiný objekt se stejným rozhraním může mít zcela jiné atributy.
-
get/set vůbec nemusí vracet jen property, může dělat spoustu jiného. Zkratka se obecně nedoporučují, z hodné dobrého důvodu. rtrim a ltrim jsou standardně známé. Camelcase je pro tuto diskusi nepodstatný.
Jak vypadá takové api javy, např. Character či String:
https://docs.oracle.com/javase/7/docs/api/java/lang/Character.html
https://docs.oracle.com/javase/7/docs/api/java/lang/String.html
Kolik je tam jednoslovných metod?
Mám rád knihovnu java joda time, která v podstatě přešla do javy 8. Jaké má API, jednoslovné metody? http://www.joda.org/joda-time/apidocs/index.html Téměř vždy sloveso + něco, často přídavné jméno a podstatné jm. Používáním v kódu vznikají docela čitelné anglické věty, velice přehledný kód.
I v pythonu jednoslovných metod (nepočítám zkratky) zase tolik není. Líbí se mi knihovna pathlib, i tady moc čistě jednoslovným metod není (opět nepočítám obecně známé zkratky, které jinde neexistují) https://docs.python.org/3/library/pathlib.html#methods-and-properties .
Budu konvertovat svůj standalone kód https://github.com/pavhofman/aio do několika rozšíření pro projekt mopidy https://github.com/mopidy/mopidy . Mopidy považuji za poměrně slušně napsaný a ve své oblasti hodně úspěšný, existuje pro něj mraky rozšíření https://github.com/search?utf8=%E2%9C%93&q=mopidy&type= . Kolik má kód mopidy jednoslovných metod?
Vážně si to nedovedu představit. A hlavně nechápu, k čemu by to bylo dobré.
-
Kite, tvé obecné vyprávění už jsme všichni slyšeli tisíckrát. Ukaž kód, kde to tak děláš. Třeba se poučíme.
-
protože u vlastních tříd nám obvykle stačí 3-5 veřejných metod. Pokud ty metody pojmenuješ sémanticky, tak ti to jedno slovo obvykle stačí.
Tvůj kód má jenom veřejné metody? A co ty ostatní, kterých bývá podstatně víc než veřejných. Nebo snad 4-úrovňové špagety ve veřejných?
-
protože u vlastních tříd nám obvykle stačí 3-5 veřejných metod. Pokud ty metody pojmenuješ sémanticky, tak ti to jedno slovo obvykle stačí.
Tvůj kód má jenom veřejné metody? A co ty ostatní, kterých bývá podstatně víc než veřejných. Nebo snad 4-úrovňové špagety ve veřejných?
Mám dostatečnou slovní zásobu na to, abych dokázal pojmenovat všechny metody, nejen veřejné. Špagety nevedu, ale často je refaktoruji po druhých. Není na tom nic těžkého, není na to potřeba ani IDE. Zkus to.
-
Metoda něco dělá, takže minimálně sloveso (co dělá, přísudek) a téměř vždy k tomu nějaké podstatné jméno "čemu" (předmět). Často ještě upřesněné přídavným jménem. Nedovedu si představit, jak metody obsahující např. inicializaci konkrétních bloků subkomponent nějaké hlavní komponenty (můj příklad rozpadu dlouhého lineárního kódu) mohou mít jednoslovný název.
Tvé jednoslovné názvy by mě opravdu zajímaly. Buď máš vše do posledního detailu rozdělené do minimalistických tříd s pár metodami (čemuž nevěřím), nebo jsou názvy nedostatečně popisné a anglicky nesrozumitelné. Protože jednoslovné metody by znamenaly, že tím předmětem je implicitní "itself" - load itself, store itself, initialize itself, atd. Ukaž nějaký kód, ale to už tě tu žádalo spoustu lidí.
to itself je instance objektu, volání metody je pak podmět.přísudek(předmět+příslovečná_určení) a nebo v anglické větě SVOMPT who.do(what, where, how, when)
-
get/set vůbec nemusí vracet jen property, může dělat spoustu jiného. Zkratka se obecně nedoporučují, z hodné dobrého důvodu. rtrim a ltrim jsou standardně známé. Camelcase je pro tuto diskusi nepodstatný.
Jak vypadá takové api javy, např. Character či String:
https://docs.oracle.com/javase/7/docs/api/java/lang/Character.html
https://docs.oracle.com/javase/7/docs/api/java/lang/String.html
Kolik je tam jednoslovných metod?
Mám rád knihovnu java joda time, která v podstatě přešla do javy 8. Jaké má API, jednoslovné metody? http://www.joda.org/joda-time/apidocs/index.html Téměř vždy sloveso + něco, často přídavné jméno a podstatné jm. Používáním v kódu vznikají docela čitelné anglické věty, velice přehledný kód.
I v pythonu jednoslovných metod (nepočítám zkratky) zase tolik není. Líbí se mi knihovna pathlib, i tady moc čistě jednoslovným metod není (opět nepočítám obecně známé zkratky, které jinde neexistují) https://docs.python.org/3/library/pathlib.html#methods-and-properties .
Budu konvertovat svůj standalone kód https://github.com/pavhofman/aio do několika rozšíření pro projekt mopidy https://github.com/mopidy/mopidy . Mopidy považuji za poměrně slušně napsaný a ve své oblasti hodně úspěšný, existuje pro něj mraky rozšíření https://github.com/search?utf8=%E2%9C%93&q=mopidy&type= . Kolik má kód mopidy jednoslovných metod?
Vážně si to nedovedu představit. A hlavně nechápu, k čemu by to bylo dobré.
Osobne nepovazuji pojmenovani za dulezite, ale kdyz uz tady chcete poucovat o spravnych nazvech metod, tak byste si mohl alespon precist PEP8.
-
pathlib.Path obsahuje 19 dvouslovnych z 80 metod.
-
Itself je anglicky předmět (česky zvratné zájmeno se/si), ne podmět.
-
Osobne nepovazuji pojmenovani za dulezite
Pak ovšem nemáme o čem diskutovat. Správné a výstižné pojmenování je z mé a nejen mé zkušenosti zcela a naprosto zásadní. Při nesprávných názvech vzniká spoustu chyb, lovíme je v našem legacy kódu obden. Každý jazyk má formát pojmenování jinak, ale princip je vždy stejný - výstižnost.
Pathlib.Path má spoustu zkratek (odpovídajících běžně známým příkazům - mkdir, chmod) a spojených slov do jednoho (expanduser). Významově jsou víceslovná.
-
Víceslovné metody ukazují na nepromyšlený málo abstraktní ad hoc návrh. Jednoslovní metoda proto, aby ji bylo možnou použít u různých objektů s významem daným objektem. Jednoslovní metody pak vedou na jakýsi pomyslný normální návrh, který vychází ze společného sdíleného mentálního a archetypálního modelu světa.
Když použijete mail.send_order(supplier, products) a mail.send_invoice(customer, products) vede to na procedurální návrh, a ne objektový, či funkcionální. Když pak potřebujete přidat zaslání poptávky, musíte vytvořit objekt poptávka a přidat metodu send_demand v objektu mail. Místo mail.send(DemandMail(supplier)) se standardizovaným komunikačním rozhraním pro objekt Mail.
-
Osobne nepovazuji pojmenovani za dulezite
Pak ovšem nemáme o čem diskutovat. Správné a výstižné pojmenování je z mé a nejen mé zkušenosti zcela a naprosto zásadní. Při nesprávných názvech vzniká spoustu chyb, lovíme je v našem legacy kódu obden. Každý jazyk má formát pojmenování jinak, ale princip je vždy stejný - výstižnost.
Pathlib.Path má spoustu zkratek (odpovídajících běžně známým příkazům - mkdir, chmod) a spojených slov do jednoho (expanduser). Významově jsou víceslovná.
zkratky jako chmod, rglob, cwd apod.povazuji za jedno slovo. Dvouslovne nazvy obsahuji podtrzitko uprostred nazvu.
-
Itself je anglicky předmět (česky zvratné zájmeno se/si), ne podmět.
A právě předmět by měl být významově nepodstatný, nemůžete konstruovat metody závislé na předmětu, což se dokonce projeví v jejich jménu. To je chyba návrhu. Metody mají být průtokové, do jisté míry bezstavové, mají pracovat s definovaným rozhraním argumentů, nikoliv významově s argumenty samotnými. Nemáte si v objektu ukládat stav argumentu, ale argumentu posílat zprávy o stavu objektu vlastnícímu danou metodu, či je použít jako argument dalších metod objektu.
Jinak na tom, překládat si () jako se/si či itself, nevidím nic špatného a neanglického, či dokonce zamlčeného. To se/si tam je, jen je zapsáno slovem ().
-
Osobne nepovazuji pojmenovani za dulezite
Pak ovšem nemáme o čem diskutovat. Správné a výstižné pojmenování je z mé a nejen mé zkušenosti zcela a naprosto zásadní. Při nesprávných názvech vzniká spoustu chyb, lovíme je v našem legacy kódu obden. Každý jazyk má formát pojmenování jinak, ale princip je vždy stejný - výstižnost.
Pathlib.Path má spoustu zkratek (odpovídajících běžně známým příkazům - mkdir, chmod) a spojených slov do jednoho (expanduser). Významově jsou víceslovná.
Zrovna tieto skratky prikazov a nazvov aplikacii mv, rm, tr, cat, chmod, awk a podobne, to je najhorsia vec na unixoch. V at&t a na berkley asi tak trosku fetovali, ked to vymyslali. Ako, rozumiem motivacii, na tty sa tazsie pisalo a cim menej pismen, tym menej preklepov, ale aj tak ...
-
Víceslovné metody ukazují na nepromyšlený málo abstraktní ad hoc návrh.
Přesně. Cílem je minimalizovat vynaložené úsilí uživatele API. Výběr správné akce by měl pokud možno provést počítač a ne uživatel na základě pročítání dokumentace desítek metod. Veřejné metody by se měly chovat inteligentně. Odhadovat záměr uživatele.
-
Veřejné metody by se měly chovat inteligentně. Odhadovat záměr uživatele.
Ja preferujem hlupejsie api. Tie kniznice, co myslia za mna len robia problemy a nutia ma robit rozne hacky a workaroundy. V tom co robim potrebujem mat presne a predvidatelne spravanie.
-
Mě by hrozně zajímalo, co přesně, páni odborníci, programujete.
-
Mě by hrozně zajímalo, co přesně, páni odborníci, programujete.
https://forum.root.cz/index.php?topic=16277.15
https://forum.root.cz/index.php?topic=16348.165
od tebe jsem tu jeste zadny kod nevidel.
-
ale kdyz uz tady chcete poucovat o spravnych nazvech metod, tak byste si mohl alespon precist PEP8.
Kde se v PEP8 povídá o obsahu názvů? Vidím tam jen samou štábní kulturu, o doporučení názvů tam není nic. Jestli myslíš formální stránku - podtržítkovou notaci, ta je v této diskusi irelevantní. Textový obsah je stejný. Já nemám podtržítkovou notaci rád, jsem z Javy zvyklý na mixed case notaci a proto ji používám i ve svém pythoním kódu.
Mimochodem téměř celé PEP8 hlídá Pycharm, jen tu naming convention inspekci mám záměrně vypnutou. Ale to vážně není o popisnosti názvů.
-
Mě by hrozně zajímalo, co přesně, páni odborníci, programujete.
https://forum.root.cz/index.php?topic=16277.15
https://forum.root.cz/index.php?topic=16348.165
od tebe jsem tu jeste zadny kod nevidel.
tuším, že hu chtěl vědět jaký software tvoříte profesionálně, mě by to taky zajímalo, to odhadování zní přinejmenším zajímavě