If bez curly brackets?

[luvar]

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.

[Reklama]

[Kit]

Osobne jeste pouzivam vicenasobne ify pro dlouhe vyrazy kde je top level jako AND (&&):

Kód: [Vybrat]

if (podminka1)
if (podminka2)
if (podminka3)
if (podminka4)
{
   neco();
}

Formátovač kódu mi z toho vyrobí tohle:

Kód: [Vybrat]

if (podminka1)
if (podminka2)
if (podminka3)
if (podminka4)
{
neco();
}

[RDa]

Ale fuj! V podstatě všechny jazyky co mají { } (a co znám) neřeší moc NL

Kód: [Vybrat]

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:

Kód: [Vybrat]

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

[Kit]

Formátovač kódu mi z toho vyrobí tohle:

Kód: [Vybrat]

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

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

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.

[Zopper]

Tak nepouzivejte formatovac kodu, ktery vyzaduje extra formatovani kodu aby mohl formatovat kod na uroven ktera ma uroven

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.

[Reklama]

[em.ve]

Ne.

[xyz]

- 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)

[Ondřej Surý]

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 a od verze 15 i clang-format (directiva 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...

[Kit]

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 a od verze 15 i clang-format (directiva 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.

[Ondřej Surý]

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.

[Kit]

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.

[LeosB]

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

[Tomáš Crhonek]

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

[Kit]

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í?

[Jiří Havel]

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.