Ako formátuejte zdrojáky v C/C++? (diskuse)

[DoubleSpace]

To nejdulezitejsi si nenapsal: taby nebo mezery ?

[xkucf03]

O tom se snad nemusí diskutovat, ne? :-) Jasně, že tabulátory.

[Petr]

Proboha, tabulatory pouzivaji jen duchodci.

[Proc je vlastne nick pro anonyma povinny ?]

Konzervo vickarska! A jeste mas tab snad definovany na 8 znaku co? Nastesti na vsech projektech uz mame commit hook na formatovani zdrojaku a tak sme s tabulatorovymi zpatecniky pekne zametli a je vsude natvrdo 2x space :-P

[MakeIranBombedAgain❗]

misto tabu čtyry mezery!!!!!! :O :O :D :D ;D ;D

btw tišnovskej pro tebe asi jako nabýtku která se nevodmítá sem si všimla hele :O :O :D ;D

[m.]

Je rok 2020. Proste v editoru nastavim, co se ma stat, kdyz zmacknu tabulator/backspace a je mi to uplne jedno, jakou vypln to tam nakonec vklada. Pracuje se s tim stejne.

Ale mel jsem kolegu, kterej programoval v editoru z Midnight Commanderu ("protoze zdrojak je prece jen textovej soubor prece") a ten razil tvrde taby, protoze jinak mackal celej den mezernik jak idiot.

[kralyk z abclinuxu]

Je rok 2020. Proste v editoru nastavim, co se ma stat, kdyz zmacknu tabulator/backspace a je mi to uplne jedno, jakou vypln to tam nakonec vklada.

To bych řek, že je spíš taknějak circa 2010.

2020 řešení je psát do editoru úplně cokoli a pak akorát zmáčknout klávesovou zkratku nebo příkaz, co vyvolá formatter.

Občas když rychle dělám nějakej menší refaktor, to naprasim do editoru nějak hlava nehlava jen do tý míry, aby byla korektní syntaxe a pak jen nechám zformátovat do pěkného vzhledu automaticky...

[xkucf03]

2020 řešení je psát do editoru úplně cokoli a pak akorát zmáčknout klávesovou zkratku nebo příkaz, co vyvolá formatter.

Tohle používám u vlastních nebo nových projektů.

Pokud ale upravuješ nějakou starou věc a máš tam udělat třeba jen nějakou drobnou změnu, tak tohle opravdu není cesta. Za přeformátování celého kódu by ti ten, kdo ti bude dělat revizi kódu nebo později hledat něco v historii či dělat merge, nepoděkoval.

[:::]

2020 řešení je psát do editoru úplně cokoli a pak akorát zmáčknout klávesovou zkratku nebo příkaz, co vyvolá formatter.

Takze preformatujes cely soubor... To teda dekuju. Kdybys tohle udelal na projektu kde pracuju tak bych te hnal svinskym krokem

[kralyk z abclinuxu]

Tak to se snad rozumí samo sebou, že nebudu vytvářet diffy formátující kód někoho jinýho.

[m.]

Nooo, pokud ten cizi kod v tom souboru je spravne naformatovan, tak ten formater v nem nic nezmeni. A pokud ano, tak to bylo potreba zmenit, prece nechces mit v tom projektu kod, ktery nesplnuje standardy pro ten projekt. Samozrejme, ze tato oprava toho formatovani by mela byt samostantny commit.

[m.]

Souhlas.

[xkucf03]

Je rok 2020. Proste v editoru nastavim, co se ma stat, kdyz zmacknu tabulator/backspace a je mi to uplne jedno, jakou vypln to tam nakonec vklada. Pracuje se s tim stejne.

A jak řešíš zarovnávání? Pokud máš tvrdý limit na délku řádku a metodu s více parametry, tak se tomu nedá vyhnout.

• pouze mezery (pro odsazení i zarovnání)
• tabulátory odsadíš na patřičnou úroveň + zarovnáš mezerami
• už první parametry dáš na nový řádek a odsadíš tabulátorem, takže není potřeba nic zarovnávat
• tabulátory použiješ k odsazení i zarovnání, co to jen jde a zbytek (méně než definovaná šířka tabulátoru) dorovnáš mezerami
• nebudeš zarovnávat, i když konvence daného projektu říkají, že zarovnávat máš

?

[kralyk z abclinuxu]

pouze mezery (pro odsazení i zarovnání)

Tohle je IMO lepší jednak protože to je jednoduchý a jednak protože v terminálu a na webu se tab typicky zobrazuje se šířkou 8, což je IMO moc.

(Ano, teoreticky a někdy i prakticky se to dá přenastavit, ale to lidi typicky nedělaj.)

[xkucf03]

Výhoda tabulátorů je právě v tom, že si lidi můžou nastavit jeho šířku. Obecně mají lidé různé preference a jedna velikost nevyhovuje všem. Někomu se čte líp text odsazený na šířku dvou mezer, někomu čtyř, někomu osm… Potkal jsem i exoty, kterým vyhovovala šířka odsazení 3 nebo 6. Když ale používáš tabulátory (+ případně mezery pro zarovnání), tak tě tyto odlišnosti nemusí trápit a není potřeba se hádat, jestli je lepší 3, 4, 6, 8 nebo jiné číslo.

Zrovna ta šířka 8, která se ti zdá moc, pochází od skupiny lidí, kteří argumentují tím, že když koukáš dvacet hodin do kódu, tak máš unavené oči a takto široké odsazení ti pomůže se v tom ḱódu neztratit. Já nemám potřebu to nikomu rozmlouvat, osobně mi vyhovuje šířka 4, ale když chce někdo 8, tak ať má 8, nemám s tím problém. Případně někteří tvrdí, že větší odsazení tě podvědomě nutí se krotit co se týče zanoření metod/podmínek/cyklů/…

[kralyk z abclinuxu]

Příloha:

• code.png (181292 bytů)

Přiznám se, že mě tohle vůbec netankuje. Já potřebuju, aby se můj kód většině lidí (ie. při výchozím nastavení) slušně zobrazoval na webu a v terminálu, a způsob, jak toho dosáhnout, je nepoužívat taby. 8 mezer někomu vyhovuje, ale většině ne. Tj. řešim to jen ze svého pohledu.

Už jsem moc starej na to, abych řešil, jestli jsou všeobecně globálně lepší taby nebo mezery. To opravdu nemá smysl

Pokud jsou na nějakém projektu taby (nebo pokud je to standard v daném jazyce, jako třeba Go nebo Makefiles), tak budu prostě používat taby, je mi to jedno, hlavně když to bude konzistentní. Dtto i takové podivnosti jako 3 mezery.

V editoru mam samozřejmě vyznačené odsazení, takže vidět je dobře tak jako tak. Důležitější než nějaká konkrétní šířka odsazení jsou pro mě různé delimitery, jako třeba různé závorky a operátory, takže ty mám teď nastavené na výraznou barvu (viz příloha). To je nápad, který jsem víceméně adaptoval z tohohle talku o succint strukturách, kde řeší rychlou navigaci ve strukturovaném dokumentu. Samozřejmě z pohledu stroje (parseru), ale rozhodl jsem se to zkusit i z pohledu člověka a zatim mi přijde, že to je dobrá věc...

[Profyk]

A v tom je samozrejme i nevyhoda, ze si to kazdy nastavi jak chce. U nas panuje svoboda nastroju, aplikaci ci operacnich systemu. At si kazdy kodi v cem chce a jak chce.

Ale svoboda formatovani neexistuje, mame nastaveny formater po commitu. Zakladni vec je nastaveni pevnych mezer misto tabu. Teamy muzou hlasovat jestli chteji v projektu 4x nebo 2x space odsazeni. Vetsinou pouzivivaji 2x. Pak jeste muzou hlasovat jestli chteji zalomeni 100zn nebo 120zn. Vetsinou pouzivaji 120zn. Proc 120? Protoze az mas monitor na vysku tak pri rozumnem fontu ti vyjde zhruba tolik kodu na radek + nejaky levy okraj pro IDE

Tim ze jsou mezery misto tabu se zajisti, ze pak kod vypada vsude stejne a nezajima mne kdo jak ma nastaveny editor.

No a samozrejme nekdy nastane chvile, ze je team prevelen na starsi kody, kde formater nebyl. Pak neni co resit, na pocatku jde jeden commit co vsechny kody preformatuje. Az testing da zelenou, ze se nevloudila regrese tak az pak zacina normalni projektova prace.

No a az by nejake prase preskocilo commit hooky a dostalo ven nenaformatovane kody s taby tak je tu jeste code review (bez nej je merge zakazany), kde se ridime pravidlem "bordel ani nekoukam, rejected".

[Kate]

Preference jsou ještě v pohodě, vždycky se dá zvyknout. Argument který mě nedávno začal obracet k tabulátorům je accessibility. Programátor s vážnější vadou zraku může mít nastavené klidně půlcentimetrové písmo a odsazení si zvolí podle toho.

[MakeIranBombedAgain❗]

nóó ale mezery a taby sou proporcionálně stejně zvěčený jako celej font takže to je jakoby jedno ne?????? :O :O

[Kate]

Jenže při velké velikosti fontu může být třeba poměrně běžná šířka odsazení 4 mezery až moc a jednoznakové odsazení se čte líp.

Našla jsem článek který se toho týkal.

[xkucf03]

Já myslím, že není tak úplně pravda, že:

Nobody talks about the real reason to use Tabs over Spaces

podle mého to spadá pod ty osobní preference. To, že někdo třeba hůř vidí, může mít vliv na to, že preferuje takové a takové osazení.

Ale asi neškodí tenhle důvod/případ zmínit explicitně.

[Kate]

On je trochu rozdíl mezi „Osobně preferuji rampy místo schodů rampy“ a „Bez rampy se na vozíku nikam nedostanu“. Dokud šlo o osobní preference, tak mi nedělalo problém říct „Tak si zvykneš“, ostatně já si taky zvykám na styl jiných projektů.

[_]

Ne podle nálady, ale podle projektu. S Qt5 camelCase, s boost či bez frameworku snake_case. A je mi to fuk, hlavně aby to bylo konzistentní a čitelné (nejen mnou).

[xkucf03]

Ta nejednotnost může mít i výhody: na první pohled vidíš, jestli je to tvůj kód nebo kód knihovny/frameworku – např. mojeMetoda() vs. jejich_metoda(). Jasně, že člověk nebude svůj kód formátovat schválně jinak, ale je to pozitivní vedlejší efekt, pokud taková konstelace nastane.

[jiwopene]

K závorkám: V C a C++ preferuji psaní {} u funkcí na nový řádek, jinde na stejný řádek. Funkci jde pak překopírovat do hlavičkového souboru a jen připsat středník. Navíc nejsou { tolik rušivé po vypsání grepem.

void foo(void)
{
    if (něco) {
        /* … */
    }
}

void bar(void)
    { /* … */ }

[kubav]

Je to v zásadě jedno, za měsíc si zvyknu na cokoliv. Hlavně na to musí být styl pro clang-format a všichni nastavený editor, aby formátoval automaticky. pokud to tak není, tak se vždycky najde někdo, kdo má neustálou snahu něco změnit a pořád otravuje nekonečnými diskuzemi.

[kralyk z abclinuxu]

+1, resp. nejlépe, aby CI odmítalo kód nenaformátovaný daným clang-format nastavením.

[Josef Kufner]

K automaticky vynucenému formátování je ještě potřeba možnost to lokálně vypnout. Občas se vyskytne situace, kdy standardní formátování se vůbec nehodí.

[jiwopene]

Celkem často zarovnávám kód do sloupečků – např. makra v C, konstanty (sloupce jsou: typ, název, rovnítko, hodnota).

[kubav]

Většina nástroju podporuje anotace v komentářích.

[plostenka]

Takove problemy bych chtel mit. Spravny lidsky citelny alias ma maximalne 8 znaku [A-Z0-9#$@] :) Prvni tri znaky shodne pro modul, zbytek rozlisuje jednotlive promenne/konstanty.

[xkucf03]

Proto ve vyspělejších jazycích máš jmenné prostory…

[kralyk z abclinuxu]

Hmm. Jak je to vlastně v Javě s aliasy/re-exporty? Umí něco takového? Mám tim na mysli to, že vnitřní a vnější namespace struktura nějaké knihovny je jiná.

V některých jazycích co používám např. můžu mít foo.bar.baz.UsefulApi , kde ale tohle je pouze vnitřní (privátní) organizace a navenek je to exportováno zjednodušeně* jako foo.UsefulApi.

*) Bez implementačních detailů, bez nutnosti exponovat vnitřní strukturu, která se může měnit...

Je taky případně možné přejmenovat / vytvořit alias pro externí dependenci?

[xkucf03]

Hmm. Jak je to vlastně v Javě s aliasy/re-exporty? Umí něco takového? Mám tim na mysli to, že vnitřní a vnější namespace struktura nějaké knihovny je jiná.

V Javě je to úplně jednoduché – struktura „vnějších“ a „vnitřních“ jmenných prostorů je stejná. Občas by se hodilo to, co můžeš dělat např. v C++ pomocí using, ale zase je to takové nezáludné a přímočaré.

Bez implementačních detailů, bez nutnosti exponovat vnitřní strukturu, která se může měnit...

Tohle je běžná věc, ale používají se k tomu rozhraní. Exportuješ např. com.example.kralyk.Abc a implementace (vracená třeba z nějaké továrny) bude v jedné verzi com.example.kralyk.impl.bla.bla.HyperAbc a v jiné com.example.kralyk.impl.foo.bar.TurboAbc a uživatel ty interní názvy a interní jmenné prostory vůbec nemusí řešit resp. ani je nevidí, pokud vyloženě nechce (přes reflexi). Ve zdrojovém kódu by se na ty implementace ani neměl dostat, protože by měl záviset jen na balíčku s rozhraním. Případně třeba v OSGi bys mohl mít rozhraní i implementaci v jednom balíčku, ale exportované by bylo jen rozhraní, nikoli implementace.

Je taky případně možné přejmenovat / vytvořit alias pro externí dependenci?

Pomocí Mavenu si můžeš „přebalit“ knihovnu a mj. přejmenovat jmenné prostory. Viz Relocating Classes. Ale to jsem snad reálně ani nikde nepoužil.

[kralyk z abclinuxu]

Tohle je běžná věc, ale používají se k tomu rozhraní.

Ok, jenom pro úplnost dodám (asi to už víš), že tohle by nešlo použít pro POD/hodnotové typy, staticky dispatchované typy apod., ale tyhle věci v Javě nejsou, takže tam to není problém...

[xkucf03]

Třeba v C/C++ bys tyhle struktury nebo definice funkcí dal do hlavičkového souboru a ten bys sdílel mezi klientem a jednotlivými implementacemi, ne?

Tohle mají IMHO hezky udělané v SQLite. Tedy hezky v rámci možností céčka :-) Modul implementující rozhraní pak ani nezávisí na dynamické knihovně jádra – jen v době kompilace závisí na tom hlavičkovém souboru.

[kralyk z abclinuxu]

Třeba v C/C++ bys tyhle struktury nebo definice funkcí dal do hlavičkového souboru a ten bys sdílel mezi klientem a jednotlivými implementacemi, ne?

Záleží, je to škála. Ten příklad s těmi SQLite pluginy je jeden konec té škály, kde je maximální oddělení. Počítám, že ty pluginy se dokonce načítají nejspíš nějakým dlopen(). Na druhém konci té škály je kód, kde je potřeba těsná vazba např. kvůli výkonu a/nebo používá hodně templates.

[Ahoj]

Začínám výstižným názvem.

[Bedňa]

Hlavne píš konzistentne.
Tvoj kód:

public:
    SomeClass(int someValue) :

return (
             someValue >= 0
                 ? std::optional(someValue)

Niekde máš medzeru, niekde nie, ja by som napísal:

public:
    SomeClass (int someValue):

return (
             someValue >= 0
                 ? std::optional (someValue)

[:::]

no fuj, pred volani funkce davat mezeru... jdu blejt

ta predchozi verze je mnohem lepsi

[Bedňa]

Kľudne si píš ako chceš, ale nech je to konzistentné všade

[:::]

Ty se ale snazis udelat konzistentni veci ktere jsou ve skutecnosti jine...

if (...)

return (...)

funkce(...)

sice vypada syntakticky podobne ale semanticky je to neco jineho... Neni duvod to psat vse stejne a spis je duvod to odlisit

[Bedňa]

Ja s tým nič nenarobím, ja som Autista Keď vidím dvojbodku raz z medzerou, raz bezmedzery, rovnako zátvorky, tak to musím opraviť

[:::]

[David Heidelberg]

Normálně, už od doby DOSu:

FORMAT C:

[Bedňa]

Heh, mal by si písať komixi