Fórum Root.cz
Hlavní témata => Vývoj => Téma založeno: rooobertek 19. 06. 2025, 12:04:43
-
Ahojte,
Nedávno som mal konverzáciu s novým kolegom cca o takomto príklade:
if (a==b)
for (...)
doSomething()
A bol som šokovaný, že je zástancom (nielen) if-ov bez curly brackets. Ja som si myslel a dúfal, že táto diskusia je už mŕtva, pochovaná a zabudnutá minimálne od roku 2014 (https://www.imperialviolet.org/2014/02/22/applebug.html).
Je tu ešte niekto z tohto klubu? Môžete mi povedať svoje argumenty?
-
Máš to blbě, žádný curly brackets, ale dvojtečky. Má to bejt takhle:
if a == b:
for ...:
doSomething()
-
Já. Od té doby co jsem musel refaktorovat kód jednoho exportu, kde bylo 5-15 zavíracích závorek vedle sebe, mám k používání nadbytečných znaků fyzický odpor. Věřím že kdyby to prase, co to psalo přede mnou, nesměl používat nadbytečné závorky, tak by se v tom ztratil a musel to napsat strukturovaněji.
Programátor má rozumnět jazyku ve kterám píše kód.
-
Máš to blbě, žádný curly brackets, ale dvojtečky. Má to bejt takhle:
if a == b:
for ...:
doSomething()
Súhlasím, ale tu žiaľ nejde o Python.
-
bez { } pouzivam if jen jako oneliner:
if (isLost) lostCount++;
-
Vzdy pouzivat curly brackets!
<script>
function testWithBraces(a, b) {
if (a == b) {
for (let i = 0; i < 3; i++) {
console.log("With braces: i =", i);
console.log("This line always runs!");
}
}
}
function testWithoutBraces(a, b) {
if (a == b)
for (let i = 0; i < 3; i++)
console.log("Without braces: i =", i);
console.log("This line always runs!");
}
testWithBraces(5, 5);
// With braces: i = 0
// This line always runs!
// With braces: i = 1
// This line always runs!
// With braces: i = 2
// This line always runs!
testWithBraces(5, 6);
// Nothing
testWithoutBraces(5, 5);
// Without braces: i = 0
// Without braces: i = 1
// Without braces: i = 2
// This line always runs!
testWithoutBraces(5, 6);
// This line always runs!
</script>
-
Nepoužívať zložené zátvorky je tak super nápad, že Go a Rust to rovno zakázali.
-
Stěžovat si na závorky ... a dávat jako ukázku kód s goto ...
A já si myslel, že goto se nedoporučuje už od devadesátek
-
Stěžovat si na závorky ... a dávat jako ukázku kód s goto ...
A já si myslel, že goto se nedoporučuje už od devadesátek
Nepoužívam to ako príklad krásneho kódu. Je to extrémne známy prípad so závažnými bezpečnostnými dôsledkami, ktorý spopularizoval tento problém.
Ale áno, oči mi takmer vypadli, keď som tam videl goto. Mimochodom, aj v jadre linuxu sa nachádzajú goto (https://github.com/torvalds/linux/blob/master/kernel/acct.c).
-
ak je to nieco jednoduche, ako napr. if nasledovany return, alebo continue tak nepouzivam, ak su napr. dva if pod sebou, tak tam ich dam.
Inak sa snazim, ak je to bez zatvoriek, bud dat do jedneho riadku, alebo dat tabulator, aby to bolo vizualne jasne.
-
Stěžovat si na závorky ... a dávat jako ukázku kód s goto ...
A já si myslel, že goto se nedoporučuje už od devadesátek
Ten bug bol ale skutočne spôsobený nepoužitím zložených zátvoriek.
To goto je v tom nevinne, a je tam použite správne.
Príkaz goto sa bežne v C používa na uvoľnenie prostriedkov, obzvlášť pri chybových stavoch.
Je to zaužívaný vzor, A NIE JE NA TOM NIČ ZLÉ. Kernel je toho plný, a mnohé C knižnice tiež.
Iné jazyky to môžu mať riešené lepšie, napr. D -- scopeguard, Go -- defer, C++ -- RAII.
-
A bol som šokovaný, že je zástancom (nielen) if-ov bez curly brackets. Ja som si myslel a dúfal, že táto diskusia je už mŕtva, pochovaná a zabudnutá minimálne od roku 2014 (https://www.imperialviolet.org/2014/02/22/applebug.html).
A co na to říká samotný odkazovaný článek?
Maybe the coding style contributed to this by allowing ifs without braces, but one can have incorrect indentation with braces too, so that doesn't seem terribly convincing to me.
Jo jo, mrtvá, pochovaná a zapomenutá ::)
-
Je tu ešte niekto z tohto klubu? Môžete mi povedať svoje argumenty?
Podobně jako RDa - pro onelinery to používám běžně, pro cokoli dalšího jsem to kdysi používal taky, ale život mě hodně rychle naučil, že je to dost špatný nápad, ty chyby co tam tím člověk nadělá jsou extrémně blbě vidět.
-
Já. Od té doby co jsem musel refaktorovat kód jednoho exportu, kde bylo 5-15 zavíracích závorek vedle sebe, mám k používání nadbytečných znaků fyzický odpor. Věřím že kdyby to prase, co to psalo přede mnou, nesměl používat nadbytečné závorky, tak by se v tom ztratil a musel to napsat strukturovaněji.
Tolik závorek často nemívám ani v celé funkci, přestože je povinně používám. Možná to bylo způsobeno zbytečně hluboko zanořenými podmínkami.
-
Tolik závorek často nemívám ani v celé funkci, přestože je povinně používám. Možná to bylo způsobeno zbytečně hluboko zanořenými podmínkami.
Dost často jsem tuhle prasárnu viděl v případě, že se autor kódu slepě držel zásady že goto je fuj.
Jak už tu zaznělo výše, typicky ve funkcích, které mají několik málo rozdílných clean-upů je to naprosto legální praktika, která právě vnořená ifová pekla eliminuje.
-
Lepsi jsou kulaty zavorky.. .
(if (= a b)
(do-something)
(do-something-else))
-
Tolik závorek často nemívám ani v celé funkci, přestože je povinně používám. Možná to bylo způsobeno zbytečně hluboko zanořenými podmínkami.
Dost často jsem tuhle prasárnu viděl v případě, že se autor kódu slepě držel zásady že goto je fuj.
Jak už tu zaznělo výše, typicky ve funkcích, které mají několik málo rozdílných clean-upů je to naprosto legální praktika, která právě vnořená ifová pekla eliminuje.
Místo goto používám return.
-
Tolik závorek často nemívám ani v celé funkci, přestože je povinně používám. Možná to bylo způsobeno zbytečně hluboko zanořenými podmínkami.
Dost často jsem tuhle prasárnu viděl v případě, že se autor kódu slepě držel zásady že goto je fuj.
Jak už tu zaznělo výše, typicky ve funkcích, které mají několik málo rozdílných clean-upů je to naprosto legální praktika, která právě vnořená ifová pekla eliminuje.
Místo goto používám return.
Což jde dobře v jazycích, které mají defer/destruktory či něco podobného. Jak je třeba před každým z mnoha returnů udělat úklid, tak to začíná být nepohodlné a náchylné k opomenutí.
-
Lepsi jsou kulaty zavorky.. .
(if (= a b)
(do-something)
(do-something-else))
konečně rozumný názor! Na co potřebujeme mít více druhů závorek, když si vystačíme s jedním, s-expressions forever.
-
Lepsi jsou kulaty zavorky.. .
(if (= a b)
(do-something)
(do-something-else))
konečně rozumný názor! Na co potřebujeme mít více druhů závorek, když si vystačíme s jedním, s-expressions forever.
Pripravte sa na budúcnosť! https://github.com/stereobooster/wisp
-
Lepsi jsou kulaty zavorky.. .
(if (= a b)
(do-something)
(do-something-else))
A není tu těch závorek nějak moc? Podle mě nejsou potřeba žádné.
Ook. Ook? Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook.
Ook. Ook. Ook. Ook. Ook! Ook? Ook? Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook.
Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook? Ook! Ook! Ook? Ook! Ook? Ook.
Ook! Ook. Ook. Ook? Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook.
Ook. Ook. Ook! Ook? Ook? Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook?
Ook! Ook! Ook? Ook! Ook? Ook. Ook. Ook. Ook! Ook. Ook. Ook. Ook. Ook. Ook. Ook.
Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook! Ook. Ook! Ook. Ook. Ook. Ook. Ook.
Ook. Ook. Ook! Ook. Ook. Ook? Ook. Ook? Ook. Ook? Ook. Ook. Ook. Ook. Ook. Ook.
Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook! Ook? Ook? Ook. Ook. Ook.
Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook? Ook! Ook! Ook? Ook! Ook? Ook. Ook! Ook.
Ook. Ook? Ook. Ook? Ook. Ook? Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook.
Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook! Ook? Ook? Ook. Ook. Ook.
Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook.
Ook. Ook? Ook! Ook! Ook? Ook! Ook? Ook. Ook! Ook! Ook! Ook! Ook! Ook! Ook! Ook.
Ook? Ook. Ook? Ook. Ook? Ook. Ook? Ook. Ook! Ook. Ook. Ook. Ook. Ook. Ook. Ook.
Ook! Ook. Ook! Ook! Ook! Ook! Ook! Ook! Ook! Ook! Ook! Ook! Ook! Ook! Ook! Ook.
Ook! Ook! Ook! Ook! Ook! Ook! Ook! Ook! Ook! Ook! Ook! Ook! Ook! Ook! Ook! Ook!
Ook! Ook. Ook. Ook? Ook. Ook? Ook. Ook. Ook! Ook.
-
Místo goto používám return.
To (v céčku) ale neřeší problém, ale přidělává jinde. Takový (pseudocode) typický blok s returnem, a s chybou kterou jsem tam udelal snadno a rychle...
sock = malloc();
if (!sock) return -1;
sock->fd = socket();
if (sock->fd == -1) {
free(sock);
return -1;
}
i = bind(sock->fd, ...);
if (i) {
close(sock->fd);
free(sock);
return -1;
}
i = connect(sock->fd,...);
if (i) {
close(sock->fd);
return -1;
}
A když se člověk rozhodne tam něco dodělat, tak musí projít všechny ty cleanupy, které jsou tam 100x
-
Pripravte sa na budúcnosť! https://github.com/stereobooster/wisp
Last commit: 5 years ago :-)
Ale souhlas, rozhodně se mi to čte líp (a dokonce jsem to i znal z dřívějška). Ale i tak je to furt Lisp a čte si mi to ve srovnání s "normálním" jazykem blbě...
-
Pripravte sa na budúcnosť! https://github.com/stereobooster/wisp
Last commit: 5 years ago :-)
Ale souhlas, rozhodně se mi to čte líp (a dokonce jsem to i znal z dřívějška). Ale i tak je to furt Lisp a čte si mi to ve srovnání s "normálním" jazykem blbě...
Slepá ulička zůstane slepou, i když ji nově vydláždíme.
-
Místo goto používám return.
To (v céčku) ale neřeší problém, ale přidělává jinde. Takový (pseudocode) typický blok s returnem, a s chybou kterou jsem tam udelal snadno a rychle...
sock = malloc();
if (!sock) return -1;
sock->fd = socket();
if (sock->fd == -1) {
free(sock);
return -1;
}
i = bind(sock->fd, ...);
if (i) {
close(sock->fd);
free(sock);
return -1;
}
i = connect(sock->fd,...);
if (i) {
close(sock->fd);
return -1;
}
A když se člověk rozhodne tam něco dodělat, tak musí projít všechny ty cleanupy, které jsou tam 100x
Ale to musis udelat vlastne vzdycky, jedine, ze bys mel neco jako
// ... dalsi pripadne vycistovaci procedury
close_socket:
close(socket);
free_socket:
free(socket);
-
Já mám ve zvyku používat složené závorky (bloky podle odsazení, jako má třeba Python nebo Scala, nechávám stranou) na explicitní vymezení bloku prakticky vždy. Výjimku může tvořit situace, kdy jde o zmíněný oneliner.
Dříve jsem to nedělal, kdysi dávno (dlouho před goto fail) mě to vypeklo, kdy při přidání dalšího příkazu (který možná jen dumpoval stav) omylem změnilo chování, protože jsem si neuvědomil chybějící {…}. (Pro přesnost: byl to Pascal, takže šlo o begin/end, nikoli o {…}, ale princip zůstává.)
Na druhou stranu podobné problémy může jít řešit i jinou cestou. Máme nástroje, které zformátují kód. Tytéž nástroje lze použít i ke kontrole, jestli formátování kódu odpovídá. Máme CI, které tyto nástroje může spouštět automaticky a kontrolovat kód po každém pushi. (A v některých případech ty problémy lze odhalit i zdánlivě nesouvisejícími nástroji, v případě goto fail tím vznikl unreachable code, nicméně to není univerzální řešení.) Lze obhájit nepoužívání {…} tím, že máme tyto nástroje? Možná, ale:
1. Pokud člověk jen bez kontroly zformátuje kód, mohlo by to projít. Pravda, u pull requestu by to mohlo bît do očí, a i pokud by to prošlo, nejspíš by to bylo odhaleno dříve.
2. Ač obvykle nechci nabádat k davovému chování, tady mi přijde praktičtější se davu držet a psát {…}, protože novému programátorovi to bude zjevnější. Naopak ve vynechávání nevidím moc výhodu.
Samozřejmě záleží na projektu. Například u one-man-show bez ambicí na dalšího vývojáře je větší prostor pro vystoupení z davu.
-
Místo goto používám return.
To (v céčku) ale neřeší problém, ale přidělává jinde. Takový (pseudocode) typický blok s returnem, a s chybou kterou jsem tam udelal snadno a rychle...
sock = malloc();
if (!sock) return -1;
sock->fd = socket();
if (sock->fd == -1) {
free(sock);
return -1;
}
i = bind(sock->fd, ...);
if (i) {
close(sock->fd);
free(sock);
return -1;
}
i = connect(sock->fd,...);
if (i) {
close(sock->fd);
return -1;
}
A když se člověk rozhodne tam něco dodělat, tak musí projít všechny ty cleanupy, které jsou tam 100x
Dá se to řešit i pyramidou. Goto dělá vlastně totéž, jen ne strukturovaně:
struct socket_wrapper *sock = malloc(sizeof(struct socket_wrapper));
if (sock) {
sock->fd = socket(AF_INET, SOCK_STREAM, 0);
if (sock->fd != -1) {
if (bind(sock->fd, ...) == 0) {
if (connect(sock->fd, ...) == 0) {
// Všechno v pořádku
return sock->fd;
}
// connect selhal
}
// bind selhal
close(sock->fd);
}
// socket selhal
free(sock);
}
// malloc selhal
return -1;
-
2. Ač obvykle nechci nabádat k davovému chování, tady mi přijde praktičtější se davu držet a psát {…}, protože novému programátorovi to bude zjevnější. Naopak ve vynechávání nevidím moc výhodu.
Samozřejmě záleží na projektu. Například u one-man-show bez ambicí na dalšího vývojáře je větší prostor pro vystoupení z davu.
{…} používám všude i ve svých projektech, dokonce i když si chci jen něco vyzkoušet. Prostě jsem si na to zvykl a mám na to klávesové makro :<CR> jako v Pythonu.
-
Dá se to řešit i pyramidou. Goto dělá vlastně totéž, jen ne strukturovaně
A to niekomu príde čitateľnejšie?
A ak áno, je k tomu aj nejaký iný dôvod okrem indoktrinácie "goto bad"?
-
Dá se to řešit i pyramidou. Goto dělá vlastně totéž, jen ne strukturovaně:
Hmm, to mě připadá ne zcela optimální, nejméně hned ze dvou důvodů:
1. dost to narušuje vizuální vnímání odsazení vs flow (ok, tohle se možná dá naučit, ale vypadá to strašně)
2. obvykle těch různých cleanupů mívám mnohem méně, než podmínek, které k nim vedou (typicky tři, nějaká alokace struktury, nějakej socket, a případně je třeba dát error na vědomí protistraně), pak by se podobná konstrukce vedla jen k dost nehezkým ošklivostem
Je nějaká zásadní výhoda tohodle stylu kromě "goto bad", která mě uniká?
-
Dá se to řešit i pyramidou. Goto dělá vlastně totéž, jen ne strukturovaně:
Hmm, to mě připadá ne zcela optimální, nejméně hned ze dvou důvodů:
1. dost to narušuje vizuální vnímání odsazení vs flow (ok, tohle se možná dá naučit, ale vypadá to strašně)
2. obvykle těch různých cleanupů mívám mnohem méně, než podmínek, které k nim vedou (typicky tři, nějaká alokace struktury, nějakej socket, a případně je třeba dát error na vědomí protistraně), pak by se podobná konstrukce vedla jen k dost nehezkým ošklivostem
Je nějaká zásadní výhoda tohodle stylu kromě "goto bad", která mě uniká?
Goto by vlastně také mělo být odsazeno, protože je to větvení. V tu chvíli ztrácí goto smysl. U té pyramidy jsem se trochu rozšoupl, protože obvykle dodržuji max 4 úrovně odsazení. Navíc bych takhle tu funkci normálně nenapsal.
Goto jsem mimo assembler a Basic nikdy nepoužil. Je to snad špatně?
-
Tak tie "zbytočné" zátvorky:
if (a === b):
doSomething()
doSomethingElse()
Nie sú až tak zbytočné, ak:
1. refactoruješ, kde presunutie časti kódu do inej funkcie znamená že sa musí aj zmeniť odsadenie.
2. ak chceš napríklad volať `doSomethingElse()` pokaždé, nie len pri podmienke a === b, musíš to riešiť zmenou odsadenia (a tu je fakt veľký problém to správne riešiť).
Lenže odsadenie je "neviditeľný znak", a musíš teraz riešiť či odsadenie je `\t` alebo `\s` a koľko ich je. To je nie len náročnejšie pri parsovaní ale aj pri čítaní. V Pythonu ľahko prehliadneš či tam máš 4 medzery alebo tabulátor. Navyše rôzne nastavenia šírky tabulátoru tiež pridávajú issue. Ak zas ale riešiš medzerami, tak pre postihnutých skús použiť čítačku "medzera medzera medzera medzera funkcia doSomething". Asi už neznie lákavo.
3. IDE, intellisense a podobne má taktiež problém, o "AI", ktorá si počet medzier medzi tokenmi asi len tak jednoducho "nespracuje", nehovorím.
4. odsadenie je vizuálne odsadenie, určite by to nemalo mať v kóde význam
5. minifiers ak je potreba prenos cez HTTP a optimalizovať výkon, alebo v IoT kde je obmedzená kapacita atď, sa ti poteší že tam máš najebaných stovky zbytočných medzier namiesto pár {}.
6. ďalej je tu issue s fontami, dokonca sú špecifické znaky, ktoré sú složeným znakom medzery a iného znaku.
7. skús niekedy search & replace podľa bloku kódu, keď tam máš {} vs keď to máš celé podľa odsadenia.
8. IDE snippety, ani nehovorím aký bordel narobí zas a znova toto medzerkovanie a odsadzovanie kde kade.
9. ak máš odsadenie napríklad 2 medzerami, ale v bloku je len jedna medzera, IDE to nevie automaticky fixnúť, nevie či to má byť súčasťou bloku alebo nie. Navyše takýto kód zlyhá a hľadanie príčiny je enormne náročné (medzery "nevidíš")
10. diffovanie, ktoré sa rozbije kvôli zmene odsadenia robí krásny bordel v Pull Requestoch.
Asi už je jasné že curly brackets majú význam.
-
Goto by vlastně také mělo být odsazeno, protože je to větvení. V tu chvíli ztrácí goto smysl.
Wut?
void * alloc_res(void)
{
void *res1 = alloc_res1();
if (!res1) {
return NULL;
}
void *res2 = alloc_res2(res1);
if (!res2) {
goto free_res1;
}
void *res3 = alloc_res3(res2);
if (!res3) {
goto free_res2;
}
void *res4 = alloc_res4(res3)
if (!res4) {
goto free_res3;
}
return res4;
free_res3:
dealloc_res3(res3);
free_res2:
dealloc_res2(res2);
free_res1:
dealloc_res1(res1);
return NULL;
}
-
Ja väčšinou pri ife nedávam zátvorky, príde mi to zbytočné. Ani si nepamätám kedy som naposledy riešil bug, ktorý by bol týmto spôsobený. Ja ale v takomto prípade zvyknem jeden riadok vynechať.
if (x)
Do(x);
else
Dont(x);
Do2();
So zátvorkami mi to ríde trochu overkill a zbytočné predĺženie
if (x)
{
Do(x);
}
else
{
Dont(x);
}
Do2();
-
Tak tie "zbytočné" zátvorky:
Nie sú až tak zbytočné, ak:
1. refactoruješ, kde presunutie časti kódu do inej funkcie znamená že sa musí aj zmeniť odsadenie.
Dobrý editor se o to postará, případně můžeš označit blok a odsadit ho.
2. ak chceš napríklad volať `doSomethingElse()` pokaždé, nie len pri podmienke a === b, musíš to riešiť zmenou odsadenia (a tu je fakt veľký problém to správne riešiť).
Lenže odsadenie je "neviditeľný znak", a musíš teraz riešiť či odsadenie je `\t` alebo `\s` a koľko ich je. To je nie len náročnejšie pri parsovaní ale aj pri čítaní. V Pythonu ľahko prehliadneš či tam máš 4 medzery alebo tabulátor. Navyše rôzne nastavenia šírky tabulátoru tiež pridávajú issue. Ak zas ale riešiš medzerami, tak pre postihnutých skús použiť čítačku "medzera medzera medzera medzera funkcia doSomething". Asi už neznie lákavo.
Snížíš jedno odsazení bez ohledu na to, zda jsou tam 2, 3 nebo 4 mezery či tab. Dvakrát stisknu jednu klávesu. To je problém? Nastavení tabulátoru mám podle typu souboru. Pokud projekt vyžaduje jiné, Git umí clean a smudge. Na odsazení vždy používám tab, který je případně editorem online převeden na 2, 3 nebo 4 mezery. Ovšem autoindent je ještě lepší vychytávkou. Tady je výhoda, že u } mi automaticky sníží odsazení dalšího řádku.
3. IDE, intellisense a podobne má taktiež problém, o "AI", ktorá si počet medzier medzi tokenmi asi len tak jednoducho "nespracuje", nehovorím.
4. odsadenie je vizuálne odsadenie, určite by to nemalo mať v kóde význam
To je otázkou vkusu. Python je prostě takový, ve stylu YAML. Pascal má begin a end, který dostal i do SQL.
5. minifiers ak je potreba prenos cez HTTP a optimalizovať výkon, alebo v IoT kde je obmedzená kapacita atď, sa ti poteší že tam máš najebaných stovky zbytočných medzier namiesto pár {}.
HTTP je komprimováno, u IoT ti nic nebrání používat taby, Odsazení je úspornější než {} se středníkem. Těch "zbytečných mezer" tam není mnoho, pokud dodržuješ doporučené max 3-4 úrovně odsazení. Pokud nechceš použít tab, vystačíš si i s jednou mezerou.
6. ďalej je tu issue s fontami, dokonca sú špecifické znaky, ktoré sú složeným znakom medzery a iného znaku.
7. skús niekedy search & replace podľa bloku kódu, keď tam máš {} vs keď to máš celé podľa odsadenia.
Nic z toho se nevyskytuje před odsazením.
8. IDE snippety, ani nehovorím aký bordel narobí zas a znova toto medzerkovanie a odsadzovanie kde kade.
Ty odsazuješ mezerníkem?
9. ak máš odsadenie napríklad 2 medzerami, ale v bloku je len jedna medzera, IDE to nevie automaticky fixnúť, nevie či to má byť súčasťou bloku alebo nie. Navyše takýto kód zlyhá a hľadanie príčiny je enormne náročné (medzery "nevidíš")
10. diffovanie, ktoré sa rozbije kvôli zmene odsadenia robí krásny bordel v Pull Requestoch.
Takový kód neselže, každý blok může mít jiné odsazení. Je však doporučeno, aby bylo jednotné.
Buď máš hloupý editor, anebo nevhodné návyky.
-
Ja väčšinou pri ife nedávam zátvorky, príde mi to zbytočné. Ani si nepamätám kedy som naposledy riešil bug, ktorý by bol týmto spôsobený. Ja ale v takomto prípade zvyknem jeden riadok vynechať.
So zátvorkami mi to ríde trochu overkill a zbytočné predĺženie
if (x)
{
Do(x);
}
else
{
Dont(x);
}
Do2();
Nemusí to být delší. {} na samostatném řádku nedělám, protože k tomu nevidím důvod, Stejně tak nevidím důvod mít prázdné řádky uvnitř funkce či metody:
if (x) {
Do(x);
} else {
Dont(x);
}
Do2();
-
Nemusí to být delší. {} na samostatném řádku nedělám, protože k tomu nevidím důvod, Stejně tak nevidím důvod mít prázdné řádky uvnitř funkce či metody:
if (x) {
Do(x);
} else {
Dont(x);
}
Do2();
[/quote]
Jj, výsledok je podobný, ono to je len vec vkusu a zvyku, ja mám radšej syntax kde súvisiace zátvorky sú pod sebou, ale zdá sa, že tvoj zápis je rozšírený pri javascripte (asi aj pri čistom C), viem sa tam prispôsobiť, ale tam sa pohybujem minimálne
-
Jj, výsledok je podobný, ono to je len vec vkusu a zvyku, ja mám radšej syntax kde súvisiace zátvorky sú pod sebou, ale zdá sa, že tvoj zápis je rozšírený pri javascripte (asi aj pri čistom C), viem sa tam prispôsobiť, ale tam sa pohybujem minimálne
Používám 16px písmo, abych na to dobře viděl a zároveň chci, aby se mi metoda či funkce vešla na stránku. Závorky na samostatných řádcích mi zhoršují čitelnost, protože musím hodně jezdit očima nahoru-dolů a ztrácím přitom synchronizaci. Prostě se mi to blbě čte a opravdu nejsem placen za počet řádek.
-
Ja väčšinou pri ife nedávam zátvorky, príde mi to zbytočné. Ani si nepamätám kedy som naposledy riešil bug, ktorý by bol týmto spôsobený.
Minulý týden. A předtím taky relativně běžně.
To přehlédnutí je strašně snadný.
-
tie zatvorky pri if, to sa este da. Ale ak ma niekto vzorec a neda tam zatvorky, tak to je uz na nervy. Strasne zle sa to cita a ked mas nejaky algoritmus prepisat, tak ta moze aj porazit.
-
tie zatvorky pri if, to sa este da. Ale ak ma niekto vzorec a neda tam zatvorky, tak to je uz na nervy. Strasne zle sa to cita a ked mas nejaky algoritmus prepisat, tak ta moze aj porazit.
Není na to nějaký formátovač, který je přidá?
-
tie zatvorky pri if, to sa este da. Ale ak ma niekto vzorec a neda tam zatvorky, tak to je uz na nervy. Strasne zle sa to cita a ked mas nejaky algoritmus prepisat, tak ta moze aj porazit.
+1
Taky me to desne s*re, kdyz pri paroven programovani to kolega ignoruje, ze pry zavorky jsou zbytecne, a u kazdy pripadu stravime minuty hadkou, a pak nekdo, kdo to ma cist / kontrolovat / opravovat / rozsirovat, tam stravi 5-10 minut aby pochopil co je to za podminku. Jako by je tech par stisku klaves a par bajtu na disku zabilo.
Osobne jeste pouzivam vicenasobne ify pro dlouhe vyrazy kde je top level jako AND (&&):
if (podminka1)
if (podminka2)
if (podminka3)
if (podminka4)
{
neco();
}
Pomaha to verzovacimu systemu, kdy vidite co za cast se zmenila nebo pridala.. namisto diffu dlouheho radku.
Radeji pisu vice ifu bez { } nez resit slozite zda && patri na zacatek radku a pak to cely ma prvni a posledni zavorku nekde daleko od sebe.
Konstrukt s vicero if-ama pod sebou je jasny ze se jedna o top-level and, a neni tam zadny "or magic" kterym by se dane podminky vyradili.
-
if (podminka1)
if (podminka2)
if (podminka3)
if (podminka4)
{
neco();
}
Vskutku geniálne, teda do doby než tam niekto skúsi pridať else.
-
Osobne jeste pouzivam vicenasobne ify pro dlouhe vyrazy kde je top level jako AND (&&):
if (podminka1)
if (podminka2)
if (podminka3)
if (podminka4)
{
neco();
}
To nie, za toto zaskrtit.
if (podminka1 &&
podminka2 &&
podminka3 &&
podminka4)
{
neco();
}
V podstate to iste, ale na prvy pohlad dobre citatelne
-
tie zatvorky pri if, to sa este da. Ale ak ma niekto vzorec a neda tam zatvorky, tak to je uz na nervy. Strasne zle sa to cita a ked mas nejaky algoritmus prepisat, tak ta moze aj porazit.
+1
Taky me to desne s*re, kdyz pri paroven programovani to kolega ignoruje, ze pry zavorky jsou zbytecne, a u kazdy pripadu stravime minuty hadkou, a pak nekdo, kdo to ma cist / kontrolovat / opravovat / rozsirovat, tam stravi 5-10 minut aby pochopil co je to za podminku. Jako by je tech par stisku klaves a par bajtu na disku zabilo.
Osobne jeste pouzivam vicenasobne ify pro dlouhe vyrazy kde je top level jako AND (&&):
if (podminka1)
if (podminka2)
if (podminka3)
if (podminka4)
{
neco();
}
Pomaha to verzovacimu systemu, kdy vidite co za cast se zmenila nebo pridala.. namisto diffu dlouheho radku.
Radeji pisu vice ifu bez { } nez resit slozite zda && patri na zacatek radku a pak to cely ma prvni a posledni zavorku nekde daleko od sebe.
Konstrukt s vicero if-ama pod sebou je jasny ze se jedna o top-level and, a neni tam zadny "or magic" kterym by se dane podminky vyradili.
Ale fuj! V podstatě všechny jazyky co mají { } (a co znám) neřeší moc NL
if (a != a1
&& b != b1
&& (b2 || b3)) {
...
} else {
...
}
Pak fungují i očekávaně else, v rámci debugu můžete zakomentovat část podmínky a pro VCS to není problém ;-)
-
Jedne offtopic info. Na porovnavanie dvoch zdrojakov je fajn pouzit nieco, co tomu jazyku rozumie a porovnava s vedomostou semantiky... Napriklad difftastic (ja pouzivam priamo s git-om https://difftastic.wilfred.me.uk/git.html ). Pri xml je stale lepsie pouzit konverziu oboch porovnavanych suborov do kanonickeho tvaru, ale pre javu a podobne, to funguje fajin.
-
Osobne jeste pouzivam vicenasobne ify pro dlouhe vyrazy kde je top level jako AND (&&):
if (podminka1)
if (podminka2)
if (podminka3)
if (podminka4)
{
neco();
}
Formátovač kódu mi z toho vyrobí tohle:
if (podminka1)
if (podminka2)
if (podminka3)
if (podminka4)
{
neco();
}
-
Ale fuj! V podstatě všechny jazyky co mají { } (a co znám) neřeší moc NL
if (a != a1
&& b != b1
&& (b2 || b3)) {
...
} else {
...
}
Pak fungují i očekávaně else, v rámci debugu můžete zakomentovat část podmínky a pro VCS to není problém ;-)
No to prave nemuzete - v mem prikladu staci "//" na kteremkoliv radku - vsechny jsou si sobe rovny, kdezto ve vasem pripade to musite resit skrze /* */, ktere meni dokonce 2 ruzne radky, protoze to && pohodlne nevykomentujete. A taky vam tam chybi ty diskutovane zavorky ze slusnosti ,)
Formátovač kódu mi z toho vyrobí tohle:
if (podminka1)
if (podminka2)
if (podminka3)
if (podminka4)
{
neco();
}
Tak nepouzivejte formatovac kodu, ktery vyzaduje extra formatovani kodu aby mohl formatovat kod na uroven ktera ma uroven :D
Co napisu to plati - nechci aby me do toho jakykoliv blbej nastroj zasahoval. Mam povoleno pouze "odstranovani extra mezer z konce radku" (pac VScode to nezobrazuje, mcedit je zobrazuje), pripadne pravidlo - za poslednim radkem je jedna (nebo dve) odradkovani. Jo a hlavne.. zadne taby, at tady prilejeme na flamewar :D
-
Formátovač kódu mi z toho vyrobí tohle:
if (podminka1)
if (podminka2)
if (podminka3)
if (podminka4)
{
neco();
}
Tak nepouzivejte formatovac kodu, ktery vyzaduje extra formatovani kodu aby mohl formatovat kod na uroven ktera ma uroven :D
:D
Nezapudím formátovač, který formátuje podle běžných zvyklostí. Naformátoval to zcela správně.
Co napisu to plati - nechci aby me do toho jakykoliv blbej nastroj zasahoval. Mam povoleno pouze "odstranovani extra mezer z konce radku" (pac VScode to nezobrazuje, mcedit je zobrazuje), pripadne pravidlo - za poslednim radkem je jedna (nebo dve) odradkovani. Jo a hlavne.. zadne taby, at tady prilejeme na flamewar :D
Tyto nástroje jsou pro mne užitečné, protože odhalují chyby, které jsem přehlédl. Odstraňování extra mezer na konci řádku se mi provádí automaticky během ukládání. Za posledním řádkem mám samozřejmě vždy LF, editor mi to hlídá od instalace. Taby vs mezery mi to dělá dle mého nastavení, o firemní zvyklosti se mi stará Git clean a smudge.
-
Tak nepouzivejte formatovac kodu, ktery vyzaduje extra formatovani kodu aby mohl formatovat kod na uroven ktera ma uroven :D
Co napisu to plati - nechci aby me do toho jakykoliv blbej nastroj zasahoval. Mam povoleno pouze "odstranovani extra mezer z konce radku" (pac VScode to nezobrazuje, mcedit je zobrazuje), pripadne pravidlo - za poslednim radkem je jedna (nebo dve) odradkovani.
To funguje, když na ten soubor nikdy nesáhne nikdo jiný, než ty. Na jakémkoliv větším a dlouhodobém projektu, kde lidi přichází a odchází, je společná vynucená konvence lepší, než jakékoliv osobní preference. Protože bez ohledu na to, jak super mi moje preference přijdou, tak když je každá metoda jinak naformátovaná, protože v průběhu 20 let do toho hráblo 50 lidí, tak aby se v tom prase vyznalo. :D
-
Ne.
-
- slozene zavorky pouzivat vzdycky
- snazit se, aby IFu v kodu bylo co nejmene, pokud to jazyk umoznuje
- snazit se o stejnou uroven abstrakce v metode
- podrobneji kniha Clean code ( https://github.com/GunterMueller/Books-3/blob/master/Clean%20Code.pdf)
-
tie zatvorky pri if, to sa este da. Ale ak ma niekto vzorec a neda tam zatvorky, tak to je uz na nervy. Strasne zle sa to cita a ked mas nejaky algoritmus prepisat, tak ta moze aj porazit.
Není na to nějaký formátovač, který je přidá?
Samozřejmě, že existuje - přidávat složené závorky umí clang-tidy (directiva readability-braces-around-statements (https://clang.llvm.org/extra/clang-tidy/checks/readability/braces-around-statements.html) a od verze 15 i clang-format (directiva InsertBraces (https://clang.llvm.org/docs/ClangFormatStyleOptions.html#insertbraces)).
A naprosto mne fascinuje, že tady ani jednou nezaznělo, že se použití clang-format by mělo být naprosto povinné pro kohokoli, kdo chce, aby jeho kód mohl ještě někdy někdo číst. A naopak jsem si tady přečetl tolik hrůz, že mi to vystačí na noční můry do konce života...
-
tie zatvorky pri if, to sa este da. Ale ak ma niekto vzorec a neda tam zatvorky, tak to je uz na nervy. Strasne zle sa to cita a ked mas nejaky algoritmus prepisat, tak ta moze aj porazit.
Není na to nějaký formátovač, který je přidá?
Samozřejmě, že existuje - přidávat složené závorky umí clang-tidy (directiva readability-braces-around-statements (https://clang.llvm.org/extra/clang-tidy/checks/readability/braces-around-statements.html) a od verze 15 i clang-format (directiva InsertBraces (https://clang.llvm.org/docs/ClangFormatStyleOptions.html#insertbraces)).
A naprosto mne fascinuje, že tady ani jednou nezaznělo, že se použití clang-format by mělo být naprosto povinné pro kohokoli, kdo chce, aby jeho kód mohl ještě někdy někdo číst. A naopak jsem si tady přečetl tolik hrůz, že mi to vystačí na noční můry do konce života...
Možná používají formátovače ve svých IDE. Používám Astyle a PHP-CS-Fixer, ale spíš výjimečně, protože závorky mi obvykle nechybí a na ostatní mi vyhovuje automatika ve Vim.
-
Možná používají formátovače ve svých IDE.
No jo, ale tohle přece vůbec nefunguje v případě, že na jednom projektu dělají aspoň dva lidi. Jiné IDE, jiné nastavení, jiné preference. Formátování se musí dohodnout kolektivně a konsenzuálně, a všichni musí používat stejné formátování a stejnou verzi clang-format[1].
1. Nové verze clang-format mají tendence občas něco rozbít nebo případně opravit věci, které byly rozbité, takže se občas něco změní jenom při změně verze.
-
Možná používají formátovače ve svých IDE.
No jo, ale tohle přece vůbec nefunguje v případě, že na jednom projektu dělají aspoň dva lidi. Jiné IDE, jiné nastavení, jiné preference. Formátování se musí dohodnout kolektivně a konsenzuálně, a všichni musí používat stejné formátování a stejnou verzi clang-format[1].
1. Nové verze clang-format mají tendence občas něco rozbít nebo případně opravit věci, které byly rozbité, takže se občas něco změní jenom při změně verze.
Pokud na projektu pracuje více vývojářů, tak je obvyklé, že jsou stanovena pravidla formátování zdrojového kódu. Každý přispěvatel je povinen si podle nich nastavit své IDE, případně Git. Program clang-format vložený do konfigurace Gitu je jen jednou z možností, jak tohoto výsledku dosáhnout.
Ve Vimu mám možnost přeformátovat třeba jen jednu metodu, takže zbytek není ovlivněn a při code review není diff dlouhý přes celou třídu.
-
Možná používají formátovače ve svých IDE.
No jo, ale tohle přece vůbec nefunguje v případě, že na jednom projektu dělají aspoň dva lidi. Jiné IDE, jiné nastavení, jiné preference.
Evidentně Vám uniklo že moderní editory mají spolupráci více lidí už dávno vyřešenou: https://editorconfig.org
-
Možná používají formátovače ve svých IDE.
No jo, ale tohle přece vůbec nefunguje v případě, že na jednom projektu dělají aspoň dva lidi. Jiné IDE, jiné nastavení, jiné preference.
Evidentně Vám uniklo že moderní editory mají spolupráci více lidí už dávno vyřešenou: https://editorconfig.org
Používám VS Code
-
Možná používají formátovače ve svých IDE.
No jo, ale tohle přece vůbec nefunguje v případě, že na jednom projektu dělají aspoň dva lidi. Jiné IDE, jiné nastavení, jiné preference.
Evidentně Vám uniklo že moderní editory mají spolupráci více lidí už dávno vyřešenou: https://editorconfig.org
Používám VS Code
Hmm, co když má spolupracovník jiné IDE? Jak se domluvíte na stylu formátování?
-
Hmm, co když má spolupracovník jiné IDE? Jak se domluvíte na stylu formátování?
Česky?
To je opravdu nepředstavitelné, že by si spolu sedli, dohodli se na formátování a každý si to pak nastavil ve svém IDE?
No jo, ale tohle přece vůbec nefunguje v případě, že na jednom projektu dělají aspoň dva lidi. Jiné IDE, jiné nastavení, jiné preference. Formátování se musí dohodnout kolektivně a konsenzuálně, a všichni musí používat stejné formátování a stejnou verzi clang-format[1].
Bojím se, že na vás clang-format už zanechal stopy. On totiž dotahuje jeden z možných přístupů k formátování do extrému.
clang-format totiž zdroják rozemele na prvočinitele a pak ho skládá dohromady. Jako by cílem bylo, aby co možná nejvíce bytů z výsledného souboru bylo vygenerované deterministicky.
"všichni musí používat stejné formátování" ale může znamenat něco podstatně jiného.
Formátování se musí řídit nějakou sadou pravidel, ale ta pravidla musí pokrývat jen důležité věci. Nemusí řešit každou mezeru.
Všiml jsem si toho, když jsme ve firmě přešli z astyle na clang-format. Najednou jsme museli rozhodnout jak formátovat spoustu drobností, které do té doby vůbec nebylo třeba řešit. Astyle na to nesahal a jak to ostatní napsali bylo vždycky dobře čitelné, i když se občas lišili v nějakých drobnostech.
1. Nové verze clang-format mají tendence občas něco rozbít nebo případně opravit věci, které byly rozbité, takže se občas něco změní jenom při změně verze.
Což práve plyne z toho extrémního přístupu, jakým k tomu clang-format přistupuje.
-
No jo, ale tohle přece vůbec nefunguje v případě, že na jednom projektu dělají aspoň dva lidi. Jiné IDE, jiné nastavení, jiné preference.
Vo firme maju byt stanovene presne pravidla formatovania, pripadne sa pouziva jeden config, ktory si kazdy natiahne do svojho IDE.
-
Hmm, co když má spolupracovník jiné IDE? Jak se domluvíte na stylu formátování?
Česky?
To je opravdu nepředstavitelné, že by si spolu sedli, dohodli se na formátování a každý si to pak nastavil ve svém IDE?
Je to představitelné, ale zbytečně komplikované - takhle se to dělalo dřív, ještě než existovala moderní IDE kterým stačí dát do git repository soubor .editorconfig a IDE se podle toho nastaví automaticky (a klidně pro každý projekt jinak, čehož dosáhnout se starými IDE ve kterých pracujete na spoustě různých projektů byl velký problém).
-
Možná používají formátovače ve svých IDE.
No jo, ale tohle přece vůbec nefunguje v případě, že na jednom projektu dělají aspoň dva lidi. Jiné IDE, jiné nastavení, jiné preference.
Evidentně Vám uniklo že moderní editory mají spolupráci více lidí už dávno vyřešenou: https://editorconfig.org
Používám VS Code
Gratuluji. A tohle znáte? https://marketplace.visualstudio.com/items?itemName=EditorConfig.EditorConfig
-
Hmm, co když má spolupracovník jiné IDE? Jak se domluvíte na stylu formátování?
Česky?
To je opravdu nepředstavitelné, že by si spolu sedli, dohodli se na formátování a každý si to pak nastavil ve svém IDE?
Je to představitelné, ale zbytečně komplikované - takhle se to dělalo dřív, ještě než existovala moderní IDE kterým stačí dát do git repository soubor .editorconfig a IDE se podle toho nastaví automaticky (a klidně pro každý projekt jinak, čehož dosáhnout se starými IDE ve kterých pracujete na spoustě různých projektů byl velký problém).
Tak jsem se na to koukl. Tohle někdo používá? Vždyť to nic neumí! Akorát nastavit o kolik odsadit a ve které verzi utfka to uložit. Proč se vůbec babrat s nějakým editorconfigem, když drtivou většinu věcí musím pořešit jinak? Tech pár drobností už můžu přihodit.
BTW, ten charset je dobrý vtip. Latin1 nebo nějaké UTFko. Ve chvíli, kdy si můžu vybírat z téhle nabídky, je stejně jediná příčetná volba utf-8.
-
Možná používají formátovače ve svých IDE.
No jo, ale tohle přece vůbec nefunguje v případě, že na jednom projektu dělají aspoň dva lidi. Jiné IDE, jiné nastavení, jiné preference.
Evidentně Vám uniklo že moderní editory mají spolupráci více lidí už dávno vyřešenou: https://editorconfig.org
Evidentně jsem se vůbec nekoukl, co ten clang-format všechno umí, pokud navrhujete editorconfig.
Tohle:
indent_style: set to tab or space to use hard tabs or soft tabs respectively.
indent_size: a whole number defining the number of columns used for each indentation level and the width of soft tabs (when supported). When set to tab, the value of tab_width (if specified) will be used.
tab_width: a whole number defining the number of columns used to represent a tab character. This defaults to the value of indent_size and doesn't usually need to be specified.
end_of_line: set to lf, cr, or crlf to control how line breaks are represented.
charset: set to latin1, utf-8, utf-8-bom, utf-16be or utf-16le to control the character set.
trim_trailing_whitespace: set to true to remove any whitespace characters preceding newline characters and false to ensure it doesn't.
insert_final_newline: set to true to ensure file ends with a newline when saving and false to ensure it doesn't.
root: special property that should be specified at the top of the file outside of any sections. Set to true to stop .editorconfig files search on current file.
je naprosto směšná a pro spolupráci nepoužitelná podmnožina formátování zdrojových kódů.
-
To je opravdu nepředstavitelné, že by si spolu sedli, dohodli se na formátování a každý si to pak nastavil ve svém IDE?
Ano. Pokud ten styl nevynucuje následně CI, tak nemá smysl se o to ani pokoušet, protože každý člověk v týmu do toho přinese nějakou vlastní kreativitu.
Ostatně jde tohle vidět i na novějších jazycích, že mají formátování zdrojáků nativně viz go fmt, a rustfmt.
Bojím se, že na vás clang-format už zanechal stopy.
Díky za pochvalu! :-D
On totiž dotahuje jeden z možných přístupů k formátování do extrému.
Přesně! A je to dobře.
-
Tak jsem se na to koukl. Tohle někdo používá? Vždyť to nic neumí! Akorát nastavit o kolik odsadit a ve které verzi utfka to uložit. Proč se vůbec babrat s nějakým editorconfigem, když drtivou většinu věcí musím pořešit jinak? Tech pár drobností už můžu přihodit.
BTW, ten charset je dobrý vtip. Latin1 nebo nějaké UTFko. Ve chvíli, kdy si můžu vybírat z téhle nabídky, je stejně jediná příčetná volba utf-8.
A vidíte, v něčem se shodneme (v tom, že editorconfig je k ničemu), a v něčem ne (třeba je to taky tím, že můj tým je geograficky roztroušen od Kalifornie po Austrálii).
-
To je opravdu nepředstavitelné, že by si spolu sedli, dohodli se na formátování a každý si to pak nastavil ve svém IDE?
Ano. Pokud ten styl nevynucuje následně CI, tak nemá smysl se o to ani pokoušet, protože každý člověk v týmu do toho přinese nějakou vlastní kreativitu.
Ostatně jde tohle vidět i na novějších jazycích, že mají formátování zdrojáků nativně viz go fmt, a rustfmt.
Bojím se, že na vás clang-format už zanechal stopy.
Díky za pochvalu! :-D
On totiž dotahuje jeden z možných přístupů k formátování do extrému.
Přesně! A je to dobře.
Na tohle jsem přesně narážel. Ona existuje určitá míra formátovací volnosti, kterou odhalíte jen pomocí striktního formátovače a diffu. Když na to kouká člověk, tak je to zformátované dostatečně stejně, aby to při čtení nijak nevadilo.
Můžete to i zaintegrovat do CI. Stačí použít tool, který zdroják "formátuje" místo toho aby ho "rekonstruoval z ASTčka".
Pravidla, která ten formátovač vynucuje, nemusí jednoznačně definovat každou mezeru.
Nějaká vlastní kreativita (v mezích pravidel, která se ale netýkají jen formátování) se přece očekává a hlídá se to přes code review. Opravdu je cílem ji zkoncentrovat do tokenů mezi whitespacy, nebo je to jen omezení použitého nástroje?
-
Nějaká vlastní kreativita (v mezích pravidel, která se ale netýkají jen formátování) se přece očekává a hlídá se to přes code review. Opravdu je cílem ji zkoncentrovat do tokenů mezi whitespacy, nebo je to jen omezení použitého nástroje?
Jenže mi naprosto vyhovuje to, že můžu zdroják libovolně nabouchat jak mi to přijde pod ruku, a pak udělám Ctrl-x Ctrl-s a mám jednotný styl. Tím pádem nemusím přemýšlet nad zalamováním řádků a podobnými nepodstatnými věcmi (forma) a můžu se soustředit jen na funkcionalitu (obsah).
Ze života bych to přirovnal k automatické převodovce - umím jezdit i s manuálem, ale neskutečně mě to sere, a ubírá mi to pozornost, kterou jinak můžu věnovat ostatním účastníkům silničního provozu, a jedu tím pádem bezpečněji.
-
Nějaká vlastní kreativita (v mezích pravidel, která se ale netýkají jen formátování) se přece očekává a hlídá se to přes code review. Opravdu je cílem ji zkoncentrovat do tokenů mezi whitespacy, nebo je to jen omezení použitého nástroje?
Jenže mi naprosto vyhovuje to, že můžu zdroják libovolně nabouchat jak mi to přijde pod ruku, a pak udělám Ctrl-x Ctrl-s a mám jednotný styl. Tím pádem nemusím přemýšlet nad zalamováním řádků a podobnými nepodstatnými věcmi (forma) a můžu se soustředit jen na funkcionalitu (obsah).
Jenže tohle udělá i podstatně méně striktní astyle. Jenom když to třeba někde sám zalomím, protože to tam zrovna dává smysl, tak mi to nepřeválcuje.
-
Jenže tohle udělá i podstatně méně striktní astyle. Jenom když to třeba někde sám zalomím, protože to tam zrovna dává smysl, tak mi to nepřeválcuje.
Myslím si, že my dva se tady dohadujeme jakou barvu má mít přístřešek na kola zatímco zbytek jezdí na mokrých sedadlech :).
Vyzkoušeli jsme toho tenkrát v roce 2017 docela dost různých variant a nakonec jsme skončili u clang-format. Je ale docela možné, že astyle nám tenkrát v týmu utekl, protože si jej nepamatuju. Ale zkoušeli jsme teď nástrojů více.
-
Jenže tohle udělá i podstatně méně striktní astyle. Jenom když to třeba někde sám zalomím, protože to tam zrovna dává smysl, tak mi to nepřeválcuje.
Myslím si, že my dva se tady dohadujeme jakou barvu má mít přístřešek na kola zatímco zbytek jezdí na mokrých sedadlech :).
Vyzkoušeli jsme toho tenkrát v roce 2017 docela dost různých variant a nakonec jsme skončili u clang-format. Je ale docela možné, že astyle nám tenkrát v týmu utekl, protože si jej nepamatuju. Ale zkoušeli jsme teď nástrojů více.
Neřešíme spíš barvu přístřešku, který už dávno stojí? ;)
My právě v práci přecházíme z astyle na clang-format, takže můžu srovnávat.
-
Neřešíme spíš barvu přístřešku, který už dávno stojí? ;)
Tak jsem to myslel :), že už řešíme jenom barvu... (samozřejmě, že starorůžová :-P)
-
Nějaká vlastní kreativita (v mezích pravidel, která se ale netýkají jen formátování) se přece očekává a hlídá se to přes code review. Opravdu je cílem ji zkoncentrovat do tokenů mezi whitespacy, nebo je to jen omezení použitého nástroje?
Jenže mi naprosto vyhovuje to, že můžu zdroják libovolně nabouchat jak mi to přijde pod ruku, a pak udělám Ctrl-x Ctrl-s a mám jednotný styl. Tím pádem nemusím přemýšlet nad zalamováním řádků a podobnými nepodstatnými věcmi (forma) a můžu se soustředit jen na funkcionalitu (obsah).
Me by se libilo formu a obsah uplne oddelit...
Nepotrebuju jednoty styl chci u sebe svuj styl a kazdej at si ma svuj.
Casto musim koukat do nekolika projektu kde kazdy to ma trochu jinak a ja bych to chtel videt vsechno stejne...
Kdybych si mohl nakonfigurovat neco jako lokalni stylesheet pro svoje editory a kdyz nahodou potrebuju i neco napsat tak treba nejakej commit hook at to predela do stylu daneho projektu...
-
Me by se libilo formu a obsah uplne oddelit...
Nepotrebuju jednoty styl chci u sebe svuj styl a kazdej at si ma svuj.
Casto musim koukat do nekolika projektu kde kazdy to ma trochu jinak a ja bych to chtel videt vsechno stejne...
Kdybych si mohl nakonfigurovat neco jako lokalni stylesheet pro svoje editory a kdyz nahodou potrebuju i neco napsat tak treba nejakej commit hook at to predela do stylu daneho projektu...
Souhlas.
Představoval jsem si "databázi" funkcí. Vyhledám si funkci, a "vyexportuju" si v podobě, jak chci já. Na to musí být připravený verzovací systém, aby dokázal zobrazit změny/rozdíly, a ve správném formátu.
Asi by muselo hodně věcí spolupracovat.
Asi málo muziky za hodně peněz.
-
Me by se libilo formu a obsah uplne oddelit...
Nepotrebuju jednoty styl chci u sebe svuj styl a kazdej at si ma svuj.
Casto musim koukat do nekolika projektu kde kazdy to ma trochu jinak a ja bych to chtel videt vsechno stejne...
Kdybych si mohl nakonfigurovat neco jako lokalni stylesheet pro svoje editory a kdyz nahodou potrebuju i neco napsat tak treba nejakej commit hook at to predela do stylu daneho projektu...
To je zajímavá myšlenka. Programový kód je vlastně serializovaným derivačním stromem. V principu by mělo jít tentýž program prezentovat v různých jazycích a formátech.
-
Nějaká vlastní kreativita (v mezích pravidel, která se ale netýkají jen formátování) se přece očekává a hlídá se to přes code review. Opravdu je cílem ji zkoncentrovat do tokenů mezi whitespacy, nebo je to jen omezení použitého nástroje?
Jenže mi naprosto vyhovuje to, že můžu zdroják libovolně nabouchat jak mi to přijde pod ruku, a pak udělám Ctrl-x Ctrl-s a mám jednotný styl. Tím pádem nemusím přemýšlet nad zalamováním řádků a podobnými nepodstatnými věcmi (forma) a můžu se soustředit jen na funkcionalitu (obsah).
Me by se libilo formu a obsah uplne oddelit...
Nepotrebuju jednoty styl chci u sebe svuj styl a kazdej at si ma svuj.
Casto musim koukat do nekolika projektu kde kazdy to ma trochu jinak a ja bych to chtel videt vsechno stejne...
Kdybych si mohl nakonfigurovat neco jako lokalni stylesheet pro svoje editory a kdyz nahodou potrebuju i neco napsat tak treba nejakej commit hook at to predela do stylu daneho projektu...
tak pro jednoduchost ten kod muze byt na jednom radku s minimem mezer a kazdy si to pak preformatuje podle sebe 😁
-
Ze života bych to přirovnal k automatické převodovce - umím jezdit i s manuálem, ale neskutečně mě to sere, a ubírá mi to pozornost, kterou jinak můžu věnovat ostatním účastníkům silničního provozu, a jedu tím pádem bezpečněji.
SIlně pochybuju, že větší než směšně malé procento dopravních nehod bylo působeno tím, že někdo řešil řazení. Reálně vás to hlavně z nějakého mně nepochopitelného důvodu štve. Stejně tak se dá bez problémů psát a dodržovat u toho code style. Stejně, jako u toho řazení je to otázka prostě pár dnů než se to zajede.