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.
Citace od: Karmelos kdy 19. 06. 2025, 12:19:13
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
Citace od: Mmmartan kdy 19. 06. 2025, 13:36:49
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.
Citace od: Mmmartan kdy 19. 06. 2025, 13:36:49
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.
Citace od: rooobertek kdy 19. 06. 2025, 12:04:43
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?
Citace
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á ::)
Citace od: rooobertek kdy 19. 06. 2025, 12:04:43
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.
Citace od: gnat kdy 19. 06. 2025, 12:21:24
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.
Citace od: Kit kdy 19. 06. 2025, 16:50:42
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))
Citace od: Wasper kdy 19. 06. 2025, 20:15:40
Citace od: Kit kdy 19. 06. 2025, 16:50:42
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.
Citace od: Kit kdy 20. 06. 2025, 00:16:57
Citace od: Wasper kdy 19. 06. 2025, 20:15:40
Citace od: Kit kdy 19. 06. 2025, 16:50:42
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í.
Citace od: listoper kdy 19. 06. 2025, 20:56:05
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.
Citace od: Exceptions kdy 20. 06. 2025, 09:27:36
Citace od: listoper kdy 19. 06. 2025, 20:56:05
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
Citace od: listoper kdy 19. 06. 2025, 20:56:05
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.
Citace od: Kit kdy 20. 06. 2025, 00:16:57
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
Citace od: balkovic kdy 20. 06. 2025, 12:36:17
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ě...
Citace od: snugar_i kdy 21. 06. 2025, 11:52:33
Citace od: balkovic kdy 20. 06. 2025, 12:36:17
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.
Citace od: Wasper kdy 20. 06. 2025, 13:54:37
Citace od: Kit kdy 20. 06. 2025, 00:16:57
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.
Citace od: Wasper kdy 20. 06. 2025, 13:54:37
Citace od: Kit kdy 20. 06. 2025, 00:16:57
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;
Citace od: Vít Šesták (v6ak) kdy 22. 06. 2025, 15:22:45
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.
CitaceDá 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"?
Citace od: Kit kdy 22. 06. 2025, 15:33:19
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á?
Citace od: Wasper kdy 22. 06. 2025, 18:28:37
Citace od: Kit kdy 22. 06. 2025, 15:33:19
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.
CitaceGoto 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();
Citace od: Mlocik97 kdy 22. 06. 2025, 19:34:49
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.
Citace od: Mlocik97 kdy 22. 06. 2025, 19:34:49
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.
Citace od: Mlocik97 kdy 22. 06. 2025, 19:34:49
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.
Citace od: Mlocik97 kdy 22. 06. 2025, 19:34:49
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.
Citace od: Mlocik97 kdy 22. 06. 2025, 19:34:49
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.
Citace od: Mlocik97 kdy 22. 06. 2025, 19:34:49
8. IDE snippety, ani nehovorím aký bordel narobí zas a znova toto medzerkovanie a odsadzovanie kde kade.
Ty odsazuješ mezerníkem?
Citace od: Mlocik97 kdy 22. 06. 2025, 19:34:49
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.
Citace od: rrrado1 kdy 22. 06. 2025, 20:56:45
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
Citace od: rrrado1 kdy 22. 06. 2025, 22:43:49
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.
Citace od: rrrado1 kdy 22. 06. 2025, 20:56:45
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.
Citace od: MalyTomi kdy 23. 06. 2025, 08:40:03
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á?
Citace od: MalyTomi kdy 23. 06. 2025, 08:40:03
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.
Citace od: RDa kdy 23. 06. 2025, 12:59:56
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
Citace od: RDa kdy 23. 06. 2025, 12:59:56
Citace od: MalyTomi kdy 23. 06. 2025, 08:40:03
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.
Citace od: RDa kdy 23. 06. 2025, 12:59:56
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();
}
Citace od: cznarg kdy 23. 06. 2025, 13:33:19
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 ,)
Citace od: Kit kdy 23. 06. 2025, 15:28:52
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
Citace od: RDa kdy 23. 06. 2025, 18:15:34
Citace od: Kit kdy 23. 06. 2025, 15:28:52
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ě.
Citace od: RDa kdy 23. 06. 2025, 18:15:34
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.
Citace od: RDa kdy 23. 06. 2025, 18:15:34
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)
Citace od: Ink kdy 23. 06. 2025, 10:39:31
Citace od: MalyTomi kdy 23. 06. 2025, 08:40:03
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...
Citace od: Ondřej Surý kdy 17. 08. 2025, 08:35:29
Citace od: Ink kdy 23. 06. 2025, 10:39:31
Citace od: MalyTomi kdy 23. 06. 2025, 08:40:03
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.
Citace od: Kit kdy 17. 08. 2025, 15:14:56
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.
Citace od: Ondřej Surý kdy 19. 08. 2025, 08:01:36
Citace od: Kit kdy 17. 08. 2025, 15:14:56
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.
Citace od: Ondřej Surý kdy 19. 08. 2025, 08:01:36
Citace od: Kit kdy 17. 08. 2025, 15:14:56
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
Citace od: LeosB kdy 19. 08. 2025, 19:09:21
Citace od: Ondřej Surý kdy 19. 08. 2025, 08:01:36
Citace od: Kit kdy 17. 08. 2025, 15:14:56
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
Citace od: Tomáš Crhonek kdy 19. 08. 2025, 21:08:05
Citace od: LeosB kdy 19. 08. 2025, 19:09:21
Citace od: Ondřej Surý kdy 19. 08. 2025, 08:01:36
Citace od: Kit kdy 17. 08. 2025, 15:14:56
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í?
Citace od: Kit kdy 19. 08. 2025, 23:34:14
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?
Citace od: Ondřej Surý kdy 19. 08. 2025, 08:01:36
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.
Citace
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.
Citace od: Ondřej Surý kdy 19. 08. 2025, 08:01:36
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.
Citace od: Jiří Havel kdy 20. 08. 2025, 08:35:06
Citace od: Kit kdy 19. 08. 2025, 23:34:14
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).
Citace od: Tomáš Crhonek kdy 19. 08. 2025, 21:08:05
Citace od: LeosB kdy 19. 08. 2025, 19:09:21
Citace od: Ondřej Surý kdy 19. 08. 2025, 08:01:36
Citace od: Kit kdy 17. 08. 2025, 15:14:56
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
Citace od: LeosB kdy 20. 08. 2025, 10:57:51
Citace od: Jiří Havel kdy 20. 08. 2025, 08:35:06
Citace od: Kit kdy 19. 08. 2025, 23:34:14
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.
Citace od: LeosB kdy 19. 08. 2025, 19:09:21
Citace od: Ondřej Surý kdy 19. 08. 2025, 08:01:36
Citace od: Kit kdy 17. 08. 2025, 15:14:56
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:
Citace
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ů.
Citace od: Jiří Havel kdy 20. 08. 2025, 08:35:06
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.
Citace od: Jiří Havel kdy 20. 08. 2025, 08:35:06
Bojím se, že na vás clang-format už zanechal stopy.
Díky za pochvalu! :-D
Citace od: Jiří Havel kdy 20. 08. 2025, 08:35:06
On totiž dotahuje jeden z možných přístupů k formátování do extrému.
Přesně! A je to dobře.
Citace od: Jiří Havel kdy 20. 08. 2025, 13:07:11
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).
Citace od: Ondřej Surý kdy 20. 08. 2025, 13:55:14
Citace od: Jiří Havel kdy 20. 08. 2025, 08:35:06
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.
Citace od: Jiří Havel kdy 20. 08. 2025, 08:35:06
Bojím se, že na vás clang-format už zanechal stopy.
Díky za pochvalu! :-D
Citace od: Jiří Havel kdy 20. 08. 2025, 08:35:06
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?
Citace od: Jiří Havel kdy 20. 08. 2025, 14:41:45
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.
Citace od: Ondřej Surý kdy 20. 08. 2025, 15:26:20
Citace od: Jiří Havel kdy 20. 08. 2025, 14:41:45
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.
Citace od: Jiří Havel kdy 20. 08. 2025, 16:57:36
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.
Citace od: Ondřej Surý kdy 20. 08. 2025, 17:31:16
Citace od: Jiří Havel kdy 20. 08. 2025, 16:57:36
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.
Citace od: Jiří Havel kdy 20. 08. 2025, 19:32:22
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)
Citace od: Ondřej Surý kdy 20. 08. 2025, 15:26:20
Citace od: Jiří Havel kdy 20. 08. 2025, 14:41:45
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...
Citace od: listoper kdy 22. 08. 2025, 14:49:53
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.
Citace od: listoper kdy 22. 08. 2025, 14:49:53
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.
Citace od: listoper kdy 22. 08. 2025, 14:49:53
Citace od: Ondřej Surý kdy 20. 08. 2025, 15:26:20
Citace od: Jiří Havel kdy 20. 08. 2025, 14:41:45
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 😁
Citace od: Ondřej Surý kdy 20. 08. 2025, 15:26:20
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.