Tabulátory, medzery a konvencie

21.11.2015 13:04 | Přečteno: 3082× | Programovanie | poslední úprava: 22.11.2015 19:46

Konvencia PEP8 je medzi programátori notoricky známa. Omnoho menej je známy výrok samotného autora pythonu: I recommend always using tabs on Unix           -- Guido.van.Rossum

V dobe keď vznikalo PEP8 mali niektoré editory skutočne problémy s tabulátormi. Celkom logicky sa v tej dobe zvolila konvencia, ktorá odporúčala používanie medzier.

Mnohí medzeristi (uznávam, to slovo som si vymyslel) argumentujú práve výrokom Guida z prezentácie Python Regrets o povolení oboch spôsobov odsadenia. Pravdu povediac nevidel som tú prezentáciu, neviem či sa týka možnosti odsadzovať tabulátorom, alebo ide len o zákaz miešania tabulátorov a medzier. Python 3 opravuje pár vecí z "Python Regrets", ale naďalej povoľuje tabulátory, takže predpokladám, že išlo len o miešanie (opravte ma ak sa mýlim).

Momentálne už nevidím problém s podporou editorov. Každý editor, s ktorým som sa stretol podporoval tabulátory korektne. Ak si pozriem hlasovanie na abclinuxu z roku 2005 a potom z 2012 vyzerá to, že počet používateľov tabulátora stúpa.

*Doplnené

Zaujímavá anketa k téme je napr. anketa o odsadzovaní neovimu.

Oficiálny priezkum na stackoverflow.

Sú jazyky, ktoré nedávajú na výber. Napríklad také Makefile, ktoré vyžaduje odsadenie tabulátorom. To dokážem pochopiť, do istej miery sa tým zjednoduší parser (nemusí sa rozpoznávať šírka odsadenia, alebo počítať znaky). Naopak také http://yaml.org/spec/current.html#id2519916 vyžaduje medzery, ale nevyžaduje striktný počet medzier a nevadí mu dokonca miešanie odsadenia 1 medzerou s odsadením 3 medzerami.

Prehľad konvencií

Konvencia	Odsadenie
Google C++ Style Guide	2 medzery
Webkit	4 medzery
Mozilla	2 medzery
Linux kernel	tabulátor
Python	4 medzery
PHP	4 medzery
Rust	4 medzery
Ruby	2 medzery
Javascript (NPM)	Tabs are better ... uses 2 spaces
Javascript (Google)	2, 4 medzery, podľa počasia
Javascript Standard Style	2 medzery
Java (oracle)	nešpecifikované

Nevýhody tabulátorov sa v súčasnosti zredukovali na jednu drobnosť - zarovnanie. Taký rust napríklad zakazuje zarovnávanie, takže nebol by problém používať tabulátory.

Napriek stúpajúcej preferencii tabulátorov stále vznikajú editory, ktoré majú predvolené používanie medzier. Dokonca staré editory postupne vnucujú medzery namiesto tabulátorov. Novo vznikajúce konvencie tak isto preferujú medzery pred tabulátormi. Nie je čas na zmenu konvencií?

Tipy na používanie tabulátorov

Ešte na koniec odbočím trochu od témy a skúsim tu zhrnúť pár rád pre používateľov tabov.

Nikdy nezarovnávať

Znie kruto, čo? Ale teraz vážne. Zarovnávanie robí bordel v histórií VCS. Stačí zmeniť dĺžku niektorého výrazu a celý zoznam sa musí preformátovať. Keď už chce niekto zarovnávať odporúčam elastic tabstops, ale zarovnávanie medzerami je zlo rovnako ako vynechanie čiarky za poslednou položkou zoznamu.

Vždy zapnuté zobrazovanie bielych znakov

Je jedno, či niekto skopíruje tabulátormi odsadený kód do medzerami odsadeného kódu, alebo opačne. Aby sa zabránilo prípadným problémom odporúčam mať zapnuté zobrazovanie bielych znakov a podľa možnosti aj zvýraznenie mixovania (ukážka priložená v glaérii).

Hmm, nejaký krátky zoznam, mal by som ešte niečo napísať

Vlastne to až tak zložité nebolo čo? Stačí byť trochu rebel, vykašlať sa na konvencie a zrazu je tu kód ktorý sa dá čítať aj s proporcionálnym fontom a každý si môže nastaviť odsadenie podľa vlastných preferencií a nemusí riešiť, či sa zdroják odsadzuje 2, 4, 8, 6, 5 (aj to som už videl), alebo 3 medzerami.

       

Obrázky

Komentáře

[kyknos]

fuj, co je spatneho na mezerach?

[mirec]

Nič ak sú 3.

[xkucf03]

• neobsahují sémantickou informaci (počet úrovní zanoření)
• člověk si nemůže nastavit šířku odsazení podle svých preferencí (jak jsi zvyklý, podle výstupního zařízení, zdrojáky z více zdrojů musíš přeformátovat ručně, abys měl šířku jednotnou…)

[kyknos]

co je proboha za problem preformatovani zautomatizovat?

hlavne je to spis, "člověk si MUSÍ nastavit šířku odsazení podle svých preferencí", při editování v "cizím" editoru, coz treba ja delam docela casto

[mirec]

Taby odsadenie, medzery zarovnanie:

if (true) {
  ->fun(int a
  ->....int b)
}

Prevedené na medzery:

if (true) {
....fun(int a
........int b)
}

Prevedené na taby:

if (true) {
  ->fun(int a
  ->  ->int b)
}

Automatizovať sa dá len ak sa nepoužíva zarovnanie. Ja zarovnanie nemám rád hlavne kvôli bordelu vo VCS, takže na mojom kóde by to teoreticky šlo.

při editování v "cizím" editoru

Niekto sa rád hrabe v cudzom počítači, iný nie. Okrem toho nevidel som nikoho kto by mal nastavenú moju preferovanú šírku (3). Medzeristi proste väčšinou používajú 2 alebo 4 medzery, nevedia sa poriadne dohodnúť na šírke. S tabmi by žiaden problém nemali. Alebo poďme všetci používať 3 medzery, je to pekne v strede, dobre sa na to pozerá.

[kyknos]

kombinovat oboji je extra prasarna :)

[mirec]

Explicitne som to v blogu označil za zlé. Niektorí to robia a je to legitímny príklad v ktorom sa stratí sémantická hodnota pri konverzii.

[BFU]

Napr. linux prave toto dela, viz checkpatch.

[kralyk z abclinuxu]

co je proboha za problem preformatovani zautomatizovat?

Jakože při otevření souboru mi to editor automaticky přeformátuje a při ukládání zase přeformátuje zpátky, aby to nedělalo bordel ve VCS? Tohle nějaký editor podporuje?

S taby tohle vůbec není problém, ale tak proč dělat věci jednoduše, když to jde i mnohem složitěji, že

[Bystroushaak]

Dá se nastavit VCS, aby ignoroval whitespaces před začátkem textu, ale souhlasím s tím, že je mnohem lepší domluvit nějakou konkrétní konvenci.

[pavlix]

Jak je to ignorování myšleno?

[Bystroushaak]

Merging without whitespace conflicts a podobné.

[kyknos]

no a jeste jednoduseji nez s taby to jde s mezerami :)

[kralyk z abclinuxu]

S mezerami nejde nic, ty tam prostě tvrdnou jak tvrdé Y

[Bedňa]

[kyknos]

btw kdyby neobsahovaly semantickou informaci o poctu urovni zanoreni, python by prestal fungovat :)

[Michal Kubeček]

Mezery nebo tabulátory, to není až tak podstatné. Podstatné je si nějaký styl zvolit a pak se ho důsledně držet. Dvěma věcem je třeba se ale zcela zásadně vyhnout: za prvé neuhlídání si nekonzistentního coding style; za druhé, když už se to stane, provádět samoúčelné tree-wide opravy formátování.

Ak si pozriem hlasovanie na abclinuxu z roku 2005 a potom z 2012 vyzerá to, že počet používateľov tabulátora stúpa.

Rok 2005 měl 365 dnů, rok 2012 už 366. Z toho je vidět, že délka roku průběžně roste.

Napríklad také Makefile, ktoré vyžaduje odsadenie tabulátorom. To dokážem pochopiť, do istej miery sa tým zjednoduší parser

I autor sám to později prohlásil za historický omyl - s nímž bohužel musíme dodnes žít. Jediné pozitivum je, že to zůstává jako odstrašující příklad pro další jazyky, že dávat whitespace syntaktický význam je zlo. Někteří se ale bohužel nepoučili.

Aby sa zabránilo prípadným problémom odporúčam mať zapnuté zobrazovanie bielych znakov a podľa možnosti aj zvýraznenie mixovania

Na to je triviální napsat si pre-commit hook, nevidím důvod, proč by s tím měl otravovat editor. Když píšu nebo prohlížím zdroják, zajímá mne zdroják, ne zvýraznění whitespace.

[mirec]

Na to je triviální napsat si pre-commit hook

Prečo každému vývojárovi do každého projektu pchať pre-commit hook keď si môže raz nastaviť editor a má to na všetky projekty?

[Michal Kubeček]

Pokud by editor prováděl kontrolu jen např. při ukládání, šlo to vypnout a šlo by konfigurovat, jaké požadavky má kontrolovat, tak proč ne. Trvalé vykreslování značek je neskutečně otravné a rušivé. Zvýrazňování "špatných" míst je ještě horší.

Obávám se, že hlavní nedorozumění je, že vy se na to díváte z pozice člověka, který si píše svůj vlastní program od začátku do konce, takže je to on, kdo si definuje pravidla a je na něm, jestli a jak je dodržuje. Já se na to dívám z pozice člověka, který musí editovat zdrojáky z různých projektů, které mají různý coding style a mnohdy obsahují hodně míst, kde ten coding style z nějakého důvodu dodržen není, ale opravovat to by nadělalo víc škody než užitku. Když si takový zdroják otevřu v editoru nastaveném podle vašich představ, bude tam na mne každou chvíli někde svítit, co je špatně - a na to opravdu nejsem zvědavý, zvlášť pokud je mým úkolem ten cizí kód, který vidím poprvé, pochopit a najít v něm chybu.

[mirec]

Ak prispievam do nejakého projektu používam štýl projektu. Ak si riešim projekt od začiatku riadim sa svojimi pravidlami.

Editor mi nehlási chyby ak je dodržané konzistentné odsadenie.

[Michal Kubeček]

Editor mi nehlási chyby ak je dodržané konzistentné odsadenie.

Na tom obrázku máte zobrazené značky na všech řádcích. To je pro mne nepřijatelné. Předpokládám, že na řádcích, kde je odsazeno špatně, to bude něco výraznějšího, aby to na problém upzornilo. A teď si představte velký projekt, který existuje roky, přispívalo do něj mnoho různých lidí a během té doby se tu a tam objevila místa neodpovídající oficiálnímu stylu. Když je budete opravovat, budou vás ostatní vývojáři milovat, až jim každou chvíli "git blame" ukáže ty vaše úklidové commity. Když je tam necháte, bude vám váš úžasný editor neustále ukazovat "tady je něco špatně".

[mirec]

Zmiešané označenie je červeným.

[xkucf03]

až jim každou chvíli "git blame" ukáže ty vaše úklidové commity

Souhlasím, že tohle je nepříjemné, ale beru to i jako nedostatek příkazu blame – stejný problém totiž nastane, když třeba někdo obalí blok kódu IFem nebo přidá odchytávání výjimky – kód je pořád stejný, ale Git jako jeho autora uvádí toho, kdo přidal if nebo try kolem.

Ideální verzovací systém (nebo samostatný „diff“ nástroj) by měl rozumět danému jazyku a měl by být schopný rozpoznat a hlásit změny typu: blok byl obalen IFem, metoda se přesunula z třídy A do třídy B nebo třeba proměnná se přejmenovala z x na y.

[Michal Kubeček]

Iniciativě se meze nekladou. :-)

Jinak máte samozřejmě pravdu, ale je určitý rozdíl mezi tím, když se musím k původu daného kusu kódu prohrábávat skrz smysluplné commity (třeba to obalení podmínkou) a když je to přes dobře míněné, ale stejně otravné změny typu "v hlavičkových souborech nepoužívejte u funkcí extern" nebo "místo porovnání s NULL použijeme všude vykřičník" (a ne, nemyslím takhle :-) ). Commity pouze opravující formátování whitespace jsou ještě o stupeň dál.

[mirec]

K tomu zobrazeniu značiek ... v ideálnom svete ich netreba. Lenže už som videl v zdrojákoch všeličo vrátane odsadenia 5. medzerami (dotyčný to kopíroval niekde z webového editoru, ktorý pri kopírovaní pridával jednu medzeru navyše). V takom prípade zobrazenie pomocných čiar (nemusia sa zobrazovať chyby, postačia pomocné čiary) zabráni zlému odsadeniu. Prirodzene v ideálnom svete by tam boli tabulátory a nikto by si nemusel robiť ťažkú hlavu s tým akú má šírku odsadenia iný programátor. Alebo všetci by mali odsadenie 3 medzery keď sa medzeristi nevedia dohodnúť či je správne číslo 2 alebo 4.

[hypvofxy]

Idea, ze si kazdy nastavi odsazeni, ktere se mu libi, je sice hezka, ale docela nesmyslna. Odsazeni samo o sobe prece coding-style nedela a pokud na projektu budou pracovat dva programatori, pricemz jeden z nich bude mit tabulator na 2 mezery a druhy na 8, potlucou se stejne minimalne kvuli delce radku. Drzel bych se standardnich 4 mezer, pokud by s tim nekdo mel fakt enormni problem, vzdycky si muze napsat plugin, ktery mu odsazeni zobrazi jinak, treba na 1 mezeru, aby to bylo originalni a mohl to vsude rozhlasovat.

[mirec]

V nových projektoch sú preferované skôr 2 medzery (rails, node, rôzne js blbosti ...)

Dĺžka riadkov bola kedysi relevantná, súčasné editory si poradia so soft wrap-om.

[hypvofxy]

Tak o JS se ani nema smysl bavit, to za seriozni jazyk nepovazuju. Delka radku je relevantni porad, protoze je fajn, aby se to alespon vlezlo na monitor.

[mirec]

Všetci programátori majú rovnakú šírku monitora, rovnaký font, rovnako rozložené okná? Ak vadí pár znakov rozdiel v šírke tabulátora potom bude vadiť aj keď niekto bude mať väčší monitor, alebo nebodaj zmení font, alebo ešte horšie upgradne knižnicu, ktorá renderuje font a zrazu tam bude u každého znaku o 1 pixel viacej!

Ale vážne, píšem v pythone, mám vodiacu čiaru na 80 znakov, občas sa dostanem na 100 čo je smiešné číslo oproti tomu čo používajú ostatní. Ukážka typického kódu s dlhými riadkami:

class CommentedStatistics(Statistics):
    def get_queryset(self):
        return (apps.get_model('comments.Comment')
            .objects
            .filter(user=self.user, parent__isnull=False)
            .values('content_type_id', 'object_id')
            .annotate(max_pk=Max('pk'), date_field=Max('created')))

    def get_graph_queryset(self):
        return (apps.get_model('comments.Comment')
            .objects
            .filter(parent__isnull=False, user=self.user))

    def get_list_queryset(self):
        return (self.get_queryset()
            .order_by('-max_pk')
            .values('content_type_id', 'object_id', 'date_field'))

[hypvofxy]

Ne, nemaji, ale pokud tu sirku zvolis rozumne, tak s tim problem nebude. Pokud kazdy developer bude mit jinou velikost odsazeni, tak ten s mensim odsazenim bude mit tim spis tendence psat hustejsi kod s vice vnorenymi konstrukcemi.

Mimochodem, driv jsem byl zastance tabulatoru a dokonce jsem mel i tendence zarovnavat promenne do sloupcu apod. Pak jsem zjistil, ze s tim jsou problemy a vsude se to zobrazuje jinak, a zvolil jsem strategii "tabulatory se pouzivaji na zacatku radku, za prvnim nebilym znakem se pouzivaji pouze mezery". Tohle michani je ale snad jeste horsi a i kdyz jsem se toho "zarovnavaciho" zvyku zbavil, ted se k mezeram priklanim proste proto, ze se kod zobrazi vsude stejne. Fakt si nemyslim, ze ta velikost odsazeni by bylo neco, s cim se da jen tak volne hybat.

Nicmene, cele se to toci kolem toho, ze ani se soucasnymi IDE a prostredky nejsou bezne rozsirene pluginy, ktere by umely programatora od low-level detailu typu "n mezer vs. tab" odabstrahovat. Jmenovite:

• BACKSPACE / DELETE odmaze N mezer naraz (jako by to bylo v pripade tabu). Misto toho lze pouzit SHIFT+TAB, ktery udela odsazeni doleva a lze jej pouzit i na vice radku soucasne, ale je potreba si zvyknout.
• nacteni "odsazovacich znaku" a jejich zobrazeni dle libovule programatora (byt s tim imho muzou byt problemy, viz vyse)

Nebylo by tak tezke to udelat a unavujici diskuze "tabs vs. spaces" muzou jednou pro vzdy skoncit (dokud nekdo nezacne resit velikost zdrojaku v bajtech). Jenze dokud to nebude umet vetsina editoru / IDE a nebude to bezna zakladni funkcionalita (podobne jako je napr. smart home), tak se o tom proste budou vest diskuze porad dokola. Jako treba ted.

Mimochodem: napr. automaticke formatovani kodu v Jave je na velmi vysoke urovni a umi to kazde IDE. Bylo by fajn, kdyby jednou bylo mozne vytvaret "projekce" kodu, tj. pro zobrazeni vytvorit lokalni kopii a naformatovat ji dle programatorova oblibeneho coding-stylu s tim, ze pred ulozenim se to zase prevede do "originalniho" coding-stylu. Komplikuje se to zejmena tim, ze by bylo potreba mit automaticke formatovani velmi dobre nastavene (a popr. podle nej upravit coding-style) a ze by bylo vhodne, aby se v originalnim kodu neprovadely zmeny na tech mistech, kde programator nic neupravoval. To ale zase muze vyustit v ruzne inkonzistence a paradoxy, takze v praxi by asi bylo nutne zvolit strategii ve stylu "preformatuj kazdy cely blok { ... }, uvnitr ktereho doslo ke zmenam".

Jeste jinak receno: ma to svoje problemy, odladit a zprovoznit neco takoveho neni uplne trivialni, ale toto by imho byla idealni cesta kudy jit, protoze pak si kazdy muze kod psat a formatovat jak se mu zlibi, aniz by to totalne rozhazelo napr. historii v Gitu.

[Bystroushaak]

Ukážka typického kódu s dlhými riadkami:

Jako by ti něco bránilo si to rozdělit na víc výrazů. A vůbec, tohle dost smrdí javascriptem a těmi jeho nekonečnými vláčky volání metod.

[mirec]

Zvážili sme rôzne spôsoby zápisu zreťazených funkcií a tento najviac zodpovedal DRY a zároveň bol medzi vývojármi najobľúbenejší.

[Bystroushaak]

*blije duhu*

[mirec]

// swap a and b
x = a
a = b
b = x

vs.

(a, b) = (b, a)

Používanie medzivýsledkov v miestach, kde to nespôsobí žiadnu pridanú hodnotu je v pythone bežne považované za antipattern. Takto by napríklad vyzeral môj kód s použitím medzivýsledkov:

class CommentedStatistics(Statistics):
    def get_queryset(self):
        commented = apps.get_model('comments.Comment').objects.all()
        commented = commented.filter(user=self.user, parent__isnull=False)
        commented = commented.values('content_type_id', 'object_id')
        commented = commented.annotate(max_pk=Max('pk'), date_field=Max('created'))
        return commented

    def get_graph_queryset(self):
        comments = apps.get_model('comments.Comment').objects.all()
        comments = comments.filter(parent__isnull=False, user=self.user)
        return comments

    def get_list_queryset(self):
        commented = self.get_queryset()
        commented = commented.order_by('-max_pk')
        commented = commented.values('content_type_id', 'object_id', 'date_field')
        return commented

Tento spôsob si nielen vyžaduje viacej písania, ale ešte sa aj horšie sa číta. Asi 1/3 kódu je boilerplate (nenapadá ma teraz slovenský ekvivalent), ktorý nemá nič spoločné s funkčnosťou.

Spôsob, ktorý používam ja je medzi djangistami pomerne bežný. Nemyslím si, že by moc pripomínal javascript. Keď niekto používa jQuery (budiž, jeho problém) tak tam je zneužívanie zreťazených funkcií časté, ale že by to bola nejaká špecifická vec pre javascript si nemyslím.

[Michal Kubeček]

Tento spôsob si nielen vyžaduje viacej písania, ale ešte sa aj horšie sa číta.

Názory jsou od toho, aby se různily.

[Bystroushaak]

(a, b) = (b, a)

vs.

a.swap(b)

Co mi na tom vadí asi je, že přenášíš funkcionalitu jazyka do metod. Třeba ten filter.

[mirec]

Příloha:

• stats.py (3921 bytů)

Co mi na tom vadí asi je, že přenášíš funkcionalitu jazyka do metod. Třeba ten filter.

To mám akože písať dotazy ručne?

Tento malý súbor napríklad rieši kompletne generovanie štatistík a zoznamov príspevkov používateľov vrátane dát pre grafy tu s možnosťou stránkovania, filtrovania zoznamov podľa typu obsahu, filtrovanie podľa dátumu ...

Len pre zaujímavosť tu je pár SQL dotazov, ktoré to generuje:

SELECT
  "article_article"."id",
  "article_article"."created",
  "article_article"."updated",
  "article_article"."title",
  "article_article"."slug",
  "article_article"."pub_time",
  "article_article"."published",
  "article_article"."pub_time" AS "date_field"
FROM "article_article"
WHERE ("article_article"."published" = %s AND "article_article"."pub_time" <= %s AND "article_article"."author_id" = %s)
ORDER BY "date_field" DESC LIMIT 20;

... podobné pre fórum, blogy ...

pre grafy:

SELECT
  django_datetime_trunc(\'month\', "article_article"."pub_time", %s) AS "time_value", 
  COUNT("article_article"."id") AS "aggregate"
FROM "article_article"
WHERE ("article_article"."published" = %s AND "article_article"."pub_time" <= %s AND "article_article"."author_id" = %s AND "article_article"."pub_time" >= %s AND "article_article"."pub_time" <= %s)
GROUP BY django_datetime_trunc(\'month\', "article_article"."pub_time", %s)
ORDER BY "time_value" ASC;

SELECT
  django_datetime_trunc(\'day\', "article_article"."pub_time", %s) AS "time_value", 
  COUNT("article_article"."id") AS "aggregate"
FROM "article_article"
WHERE ("article_article"."published" = %s AND "article_article"."pub_time" <= %s AND "article_article"."author_id" = %s AND "article_article"."pub_time" >= %s AND "article_article"."pub_time" <= %s)
GROUP BY django_datetime_trunc(\'day\', "article_article"."pub_time", %s)
ORDER BY "time_value" ASC;

SELECT
  django_datetime_trunc(\'month\', "blog_post"."pub_time", %s) AS "time_value",
  COUNT("blog_post"."id") AS "aggregate"
FROM "blog_post" INNER JOIN "blog_blog" ON ( "blog_post"."blog_id" = "blog_blog"."id" ) WHERE ("blog_post"."pub_time" < %s AND "blog_blog"."author_id" = %s AND "blog_post"."pub_time" >= %s AND "blog_post"."pub_time" <= %s)
GROUP BY django_datetime_trunc(\'month\', "blog_post"."pub_time", %s)
ORDER BY "time_value" ASC;
...

Keby som to mal písať ručne tak sa 1. zbláznim a 2. zbláznim sa keď by som potreboval pridať nejakú podmienku (povedzme do blogov by som pridal is_draft a zrazu potrebujem do všetkých dotazov mimo adminu a zobrazenia vlastných blogov podmienku is_draft = false.

[Bystroushaak]

Já ti nechci říkat, že v tomhle konkrétním případě to není vhodné. Jen jsem poznamenal, že se mi nelíbí obecně tahle praktika nekonečného řetězení.

[mirec]

Ak existuje lepší postup rád si o ňom prečítam. Ja používam Django ORM a to má zreťazené volania funkcií. Ak si pozriem povedzme SQLAlchemy tak používa rovnaké zreťazenie (dokonca hneď keď otvorím dokumentáciu vidím zreťazenie bez medzivýsledkov). Väčšina ORM nie len pre python používa zreťazené funkcie.

Ak ide len o spôsob zápisu zreťazenia .. no vyskúšali sme ich viacero. Na tento som narazil na stack overflow a zatiaľ vyhovuje najviac (i keď podobnosť s tuple je zavádzajúca, ale spätné lomítka na konci tiež nevyzerali ktovie ako dobre).

[xkucf03]

To (a, b) = (b, a) a a.swap(b) ale není ekvivalentní, ne?

Voláním metody na a nemůžu změnit, kam odkazuje proměnná a, ne? Můžu leda nastavit objektu a stejnou hodnotu (stejný vnitřní stav), jako má objekt pod proměnnou b. Kdežto ten kód se závorkami a rovnítkem prohodí to, kam proměnné a a b ukazují, ne?

[Bystroushaak]

To byla ilustrace.

[mirec]

Len tak mimochodom dokonca google odporúča odsadzovať python dvoma medzerami.

[Hans1024]

A je k doporucovani mikroskopickeho odsazeni u ceckoidnich jazyku nejaky jiny duvod, nez aby lidi mohli psat humusokod s 20 urovnemi zanoreni?

[Ondrej Santiago Zajicek]

Prekvapuje me, ze lide pocitaji odsazovani v mezerach ci tabulatorech. IMHO je rozumne odsazovat na sloupce, zda se k reprezentaci pouziji mezery ci taby je irelevantni implementacni detail (nicmene je dobre mit dohodnutou kanonickou reprezentaci).

[JS1]

Myslis jako treba v Lispu? Abych byl uprimny, trochu me Lispova konvence vadi.

Na druhou stranu, jak rikas - podle me by mel byt tab s fixnim predpokladem 8 znaku a vsude jinde pouzivat mezery, a editory by to mely respektovat. Pak s tim nejsou problemy. Ja osobne nastavuji vsechny editory na "tabs to spaces", tim se predejde nedorozumenim pri pouzivani tabulatoru (coz je IMHO ta prava pricina techto problemu s mezerami, whitespace ma syntakticky vyznam ve vsech jazycich, nikoli jen u odsazovani).

Jinak, autor zminuje makefile, ale to je spatny priklad. Nic by se nestalo, kdyby se v makefile misto tabulatoru pouzil viditelny znak. Zatimco v Pythonu by to jasne snizilo citelnost.

Osobne si myslim, ze tahle diskuse je zbytecna. Rozumny novy jazyk (jako to treba resi Go) by mel IMHO prijit s formatovacim standardem (a eventualne programem, ktery ji vynuti).

[Ondrej Santiago Zajicek]

Myslis jako treba v Lispu?

Ne, myslim proste fixni pocet sloupcu na uroven zanoreni. Pokud mam odsazeni 4 sloupce/uroven, a jsem na 5 urovni, tak mam celkove odsazeni 20 sloupcu, coz muze byt reprezentovano 2 taby a 4 mezery, 1 tab a 12 mezer ci rovnou 20 mezer (ci jine, jeste obskurnejsi varianty), to je vcelku jedno. Akorat je dobre mit kanonickou formu, aby reformatovani nevytvarelo sum.

Lispova konvence (pokud tim myslime to same) mi take vadi, prijde mi, ze casto vede k zbytecne extremnimu odsazeni.

Na druhou stranu, jak rikas - podle me by mel byt tab s fixnim predpokladem 8 znaku

Souhlasim. Resp presneji odsazeni na nejblizsi tabulacni pozici - nasobek 8.

osobne nastavuji vsechny editory na "tabs to spaces", tim se predejde nedorozumenim pri pouzivani tabulatoru

Opravdu s taby nejake problemy jsou? Mozna u nejako siroce-multiplatformniho projektu. Ale pro bezne ucely je 8 znaku defacto standard a problemy s tim ma snad akorat jen ten, kdo si sam v editoru nastavil jinou hodnotu.

[kyknos]

8 znaku? s tim jsme se setkal pouze v diskusich :) v realu jsme vsude videl akorat 4 :)

[Ondrej Santiago Zajicek]

V realu jsem nikde nevidel terminal nastaveny tak, ze by tabulator (ASCII znak 9) odsazoval na nasobky 4 sloupcu. Ano, je mozne je tak nastavit, ale mnohe editory jsou z toho zmatene a realne stejne pocitaji s nasobky 8 sloupcu.

Mluvim o tabulatorech, nikoliv o urovnich odsazeni ve zdrojovem kodu.

[kyknos]

mluvim o textovem editoru - 8 je natolik neprakticka hodnota, ze se nedivim, ze jsem to nikoho nevidel v realu pouzivat

[Ondrej Santiago Zajicek]

Ja mluvim o interpretaci znaku ASII 9 a myslim, ze tak to rozumel i JS1 v prvnim postu, ktera se tykala zminovane vety.

[kyknos]

to je ale pro me jakasi starodavna teorie zcela odtrzena od reality, proste tab v takovem kontextu vubec nepouzivam - a rekl bych ze vetsina lidi ne

[Ondrej Santiago Zajicek]

To ma naopak k realite velmi blizko - textove soubory (vcetne zdrojaku) proste taby (znaky s ASCII 9) obecne obsahuji a kazdy program, ktery ty textove soubory ma zobrazit ci editovat, musi rozumet, jak je interpretovat.

[kyknos]

no a kazdy takovy program, kde me ta interpretace nejak vizualne zajima, tedy textovy editor, pouziva jako default, pripadne jako hodnotu, na kterou si ho lide v mem okoli nastavili, 4 - osm znaku dlouhy tab jsem videl snad jen kdyz jsem si sam hral s nastavenim :)

[Ondrej Santiago Zajicek]

No, tak to se jim v takovem editoru rozsype formatovani zdrojaku treba Linux kernelu, Glibc, GCC, Coreutils, GTK a mnoha dalsich vyznamnych projektu. Namatkou jsem se podival do ruznych stazenych zdrojaku, ktere se mi povaluji na disku, a nenasel jsem projekt, ktery by zaroven taby pouzival a nepredpokladal delkou 8. Pravda, vsechny ty projekty byly v C, netusim, jake jsou zvyklosti v jinych jazycich.

[kyknos]

tak ja vubec taby ve zdrojaku nepouzivam a kdyz to nekde nahodou vidim, tak si klepu na celo :)

ale v cecku nic nepisu, do kernelu nelezu, staci mi python, obcas trosku javascriptu, lispu, julie :) obecne si myslim, ze do kernelu leze fakt mizive procento lidi, co neco programuje

[Ondrej Santiago Zajicek]

Pokud taby ve zdrojacich vubec nepouzivas, pak je vcelku jedno, na jakou delku tabu mas nastaveny editor.

[kyknos]

pouzivam odsazeni 4 mezery, stiskem klavesy tab napisu 4 mezery

samozrejme tab se mi muze zobrazovat jakkoliv, kdyz ho tam nemam, ale pro konzistenci je nastaven take na 4 mezery - a obcas se tam vyskytne od nejakeho prasatka, ale pak vetsinou skutecne predstavuje 4 mezery

[xkucf03]

8? Pro mne je standard 4. I když jsem dělal i na projektech, kde se odsazovalo na 2 nebo na těch 8. Ale vtip je právě v tom, že to nemusí být pevně dané a každý si to zobrazí, jak mu vyhovuje – tedy pokud se používají tabulátory. Jednoduše: 1 tabulátor = 1 úroveň odsazení.

Používat tabulátory a nutit lidi, aby si u nich nastavili nějakou fixní šířku mi přijde úplně zcestné – pak nemají moc výhod oproti mezerám (leda ty uspořené bajty zdrojáku).

[JS1]

Ale vtip je právě v tom

Od navrharu ASCII to byl dobry vtip. Jeho pointu podtrhly textove editory, ktere se rozhodly nahrazovat taby mezerami, pokud mozno pokazde jinak. I kdyz asi na ten spolecny vtip Billa Gatese a Steva Jobse s CR/LF to nema..

Používat tabulátory a nutit lidi, aby si u nich nastavili nějakou fixní šířku mi přijde úplně zcestné – pak nemají moc výhod oproti mezerám (leda ty uspořené bajty zdrojáku).

A ty mas na disku tak malo misto, ze potrebujes sporit u zdrojaku (i kdyz mozna jo, pokud pouzivas Javu.. :-P)?

Tabulatory (jako znak) nemaji dnes zadne vyhody oproti mezeram - je to historicky artefakt, asi jako BEL nebo RS. Jinak editor si samozrejme muze (a taky to bezne delavaji) navazat na stisk tabulatoru (klavesy) jakoukoli akci.

[Michal Kubeček]

I kdyz asi na ten spolecny vtip Billa Gatese a Steva Jobse s CR/LF to nema..

Ta idea oddělení carriage return a line feed coby dvou samostatných znaků je mnohem starší a ve své době dávala smysl. Windows ani nebyly první, kdo začal pro oddělení řádků v textových souborech používat kombinaci CRLF - koneckonců to předepisují třeba specifikace protokolů SMTP nebo HTTP. Kdybych měl Windows vytknout nějakou na hlavu postavenou volbu, které je (téměř) jedinečná, tak spíš UTF-16.

Ale lidstvo se nepoučilo, takže dneska zase máme BOM a editory, které ho cpou i do souborů kódovaných v UTF-8…

[Ondrej Santiago Zajicek]

8? Pro mne je standard 4. I když jsem dělal i na projektech, kde se odsazovalo na 2 nebo na těch 8.

Mluvim zde ciste o interpretaci znaku ASII 9, nikoliv o odsazeni pri programovani obecne.

Ten je vicemene univerzalne pouzivan pro odsazeni na tabelacni pozice po 8 sloupcich. Zkus si textovy soubor s tabulatory vycatovat v terminalu nebo zobrazit treba ve webovem prohlizeci ci e-mailu. Nebo mas i terminal a webovy prohlizec prenastaven tak, aby tabulator (znak) odsazoval na 4 pozice? A neni nesmysl, aby textovy editor narozdil od zbytku systemu zobrazoval ten samy text jinak zformatovany?

To je koneckoncu hlavni argument proti odsazovani pouze tabulatory - ty sve IDE muzes mit nastavene tak, aby chapalo znak tab ve zdrojovem kodu jako odsazeni po 4 sloupcich, ale zbytek sveta bude defaultne pouzivat 8, coz je pro ucely odsazovani ve zdrojovem kodu obvykle moc, takze nahodny clovek prohlizejici tvuj kod ho uvidi roztazeny a prekracujici delku radku.

[kralyk z abclinuxu]

A neni nesmysl, aby textovy editor narozdil od zbytku systemu zobrazoval ten samy text jinak zformatovany?

Jak jinak zformátovaný? Změna délky tabu by neměl měnit formátování.

[Bystroushaak]

8? Pro mne je standard 4.

Přidávám se k těm, kdo používají 4 znaky. Samozřejmě, že terminál to zobrazí jinak, ale kdo čte zdrojáky v terminálu?

[pc2005]

I kernel?

[Bystroushaak]

Kernel čtu jen málo (v podstatě jen tehdy, když v něm hledám bug, protože nejde zkompilovat), takže ano, i kernel.

[mirec]

Kernel používa tabulátor aj na zarovnávanie, bez nastavenia zobrazenia na 8 medzier je zdroják (presnejšie povedané zarovnané časti) rozhodený. Pri čítaní sa to tá prežiť, pri úprave nie.

[kyknos]

Prasata, co vic k tomu rict

[mirec]

Majú presne definované ako má byť nastavený a pri správnom nastavení to nerobí problém ani keď niekto mixuje medzery a tabulátory. Nepáči sa mi to no je to jednoznačne definované a ja to rešpektujem. Lepšie než keď sa na začiatku vôbec nedohodne štýl a každý robí čo chce.

[Michal Kubeček]

Přesně tak. I hloupý coding style je lepší než žádný coding style. Jsem v pokušení říct, že GNU styl (glibc) je výjimka, ale i to je pořád lepší, než když je každý kus zdrojáku formátovaný jinak podle toho, kdo ho psal a jak se zrovna vyspal.

Dodnes si nadávám, že když jsem se se rozhodl vzkřísit Twinkle, neprohnal jsem hned na začátku celý původní strom z posledního tarballu indentem nebo něčím podobným. Co se dá dělat, budiž mi to odstrašujícím příkladem pro případ, že se někdy dostanu do podobné situace znovu.

[kyknos]

Proste zlaty python

[Michal Kubeček]

Ani na čtení to není nic moc, zvlášť u nějakých složitějších víceřádkových výrazů nebo podmínek.

Na druhou stranu, o delší než osmiznakové odsazování asi nestojí nikdo a limit 80 znaků na řádek se stále ve většině kódu dodržuje (kromě dlouhých stringových konstant), přestože vůči němu sílí odpor. Takže není moc důvod, proč by si člověk ty zdrojáky nemohl číst se správnou hodnotou odsazení.

Problém to je spíš tam, kde někdo kvůli přehlednosti preferuje větší odsazení než používá projekt a zdroják se s ním nevejde na terminál.

[pc2005]

Na čtení se to dá (já své zdrojáky modulů odsazuju náhodně), ale pokud bys chtěl reportovat patch, tak i ten blbej mail musí mít správný formátování textu .

[Michal Kubeček]

Vzhledem k tomu, že celý mail se (až na část mezi oddělovačem "---" a začátkem vlastního patche) dostane do gitu, to není až tak překvapivé.

[hypvofxy]

Ta pointa je, ze pri uzivani tabulatoru zalezi na zvolene renderovaci delce, tj. kazdemu se to zobrazi jinak a ve vysledku to nemusi sedet se zbytkem formatovani. Prave proto, aby se tomu predeslo, coding-style pro Linuxovy kernel pro odsazovani predepisuje tabulatory zobrazene o sirce 8 mezer. Tim se eliminuje nejvyznamnejsi vyhoda tabulatoru, ktera byla v teto diskuzi prezentovana (tj. moznost upravit si vizualni velikost odsazeni dle libosti).

[Bystroushaak]

To chápu. Píšu prostě, že je mi fakt v prdeli, jak to kdo chce zobrazovat, zobrazuji si to na 4 mezery.

[Hans1024]

A zkousel jsi otevrit neco s GNU coding style?

[Ondrej Santiago Zajicek]

Zaprve, nejde jen o terminal, ale obecne o sirsi pristup ke zdrojakum. Zdrojaky zobrazuju v terminalu pri praci s gitem. Zdrojaky ctu v mailu kdyz nekdo posle patch. Zdrojaky ctu na webu v ramci ruznych public git web access serveru.

Zadruhe, jak uz jsem psal vyse jako odpoved kyknosovi, pokud si nastavis editor na tab = 4, tak si rozbijes formatovani u velkeho mnozstvi existujicich projektu, pokud bys jejich zdrojaky v tom editoru otviral.

[xkucf03]

pokud si nastavis editor na tab = 4, tak si rozbijes formatovani u velkeho mnozstvi existujicich projektu

Za předpokladu, že ty tabulátory používají chybně. Kdyby se používal pro odsazení o jednu úroveň, zatímco pro zarování by se používaly mezery, tak by to fungovalo správně pro jakoukoli šířku tabulátoru.

Tabulátor jako „makro pro 8 mezer“ podle mého nemá smysl – to už je lepší tam naflákat přímo ty mezery.

[pc2005]

zatímco pro zarování by se používaly mezery

I pro tabulky třeba s políčky o délce třeba 10+ znaků?

[pavlix]

Za předpokladu, že ty tabulátory používají chybně.

Jakýkoli jiný předpoklad je v kontextu linuxového vývoje chybný, Ondra už tu pár takových významných projektů jmenoval.

Tabulátor jako „makro pro 8 mezer“ podle mého nemá smysl – to už je lepší tam naflákat přímo ty mezery.

O tom se tady snad nikdo nepře.

[Bystroushaak]

Tabulátor jako „makro pro 8 mezer“ podle mého nemá smysl – to už je lepší tam naflákat přímo ty mezery.

On hlavně takhle nikdy nefungoval, protože se dynamicky dorovnává na zarovnání sloupce. Někdy tak má tři mezery a jindy osm.

[Ondrej Santiago Zajicek]

Za předpokladu, že ty tabulátory používají chybně.

Pokud si zadefinujeme 'chybne' jako 'jinak nez ty', tak ano. O zneuzivani tabu by se dalo mozna mluvit v pripade kombinovani tabu a mezer pro odsazeni (jak to defaultne dela napr. emacs), ale pouziti tabulatoru zaroven pro odsazovani a pro zarovnani je plne v souladu s tradicnim vyznamem, chovanim a uzitim tabulatoru. Ze to tobe nevyhovuje, je tvuj problem.

[kralyk z abclinuxu]

ale pouziti tabulatoru zaroven pro odsazovani a pro zarovnani je plne v souladu s tradicnim vyznamem, chovanim a uzitim tabulatoru

To imho není pravda. Používat pro zarovnání znak, který má z definice dynamickou šířku, prostě není dobrý nápad, pokud někdo chce, aby byl kód zarovnaný všude stejně. Ani v terminálu není ta šířka garantována, dá se dynamicky měnit, viz ESC H, CSI g et al.

[radix]

Driv jsem preferoval tabulatory kvuli jejich chovani v editorech - backspace se chova logicky a vrati se na predchozi uroven, ne jen odmaze jednu mezeru (coz nema zadny vyznam).

Od te doby to ale schopne editory vyresily (Intellij IDEA) a chovaji se spravne i pokud se pouziva mezery (konkretne IDEA jde v inteligenci backspace jeste dal). Z toho duvodu se ted priklanim k mezeram, protoze jeji vyhody prevazuji.

Argumenty typu kazdy muze mit rad jine odsazeni jsou pro me uplne irelevantni. Java to udelala dobre a narizuje 4 mezery dlouhe odsazeni. IMHO dobry kompromis, ktery vicemene nikdo neporusuje.

Konzistentni zobrazeni kodu je IMHO prioritni. S tabulatory jsem mel problem napriklad v normalnich textovych editorech, viewerech, diffech atp. ktere typicky za sirku tabulatoru berou 8. Zarovnani kodu je pak rozbite.

Mel jsem k tomu dlouhou cestu, ale zarovnani kodu je v nekterych pripadech uzitecne a pomaha k lepsi citelnosti kodu.

[mirec]

Taby sa nemajú používať na zarovnanie.

Možnosť zarovnávať kód mi nechýba, kedysi som si myslel, že prispieva k čitateľnosti (sám som zarovnával a prestal som s tým).

Na zarovnávanie je pekná hračka - elastic tabstops. Len akosi to poriadne skoro nikto neimplementoval.

[radix]

Ano, taby se nemaji pouzivat na zarovnavani, ale to bud musite mit inteligentni editor, ktery zvoli spravne taby nebo mezery podle kontextu, nebo se stale hlidat (a sve kolegy) jak zarovnavate. Pouzivat mezery mne prijde jednodussi.

Ja jsem to mel presne opacne - driv jsem nezarovnaval nic, vse bylo jen spravne odsazene. Dnes zarovnavam nektere veci - napr. zarovnani v builder style kodu, kde zretezene volate hodne metod - tak, aby byla videt struktura/zamer ze zarovnani. Vysledny kod je pak znatelne citelnejsi nez nezarovnany.

Elastic tabstops ma opet problem v diffech a jinych textovych toolech - nerozumi tomu. I kdyby ano, tak chybi nejaka univerzalni moznost, jak deklarovat jestli se maji nebo nemaji elastic tabstops pouzit.

Pouziti mezer tyhle problemy elegantne resi ve vsech toolech, tak proc si komplikovat zivot.

[mirec]

Elastic tabstops práve rieši diffy v prípade, že sa zmení dĺžka zarovnaných reťazcov. S medzerami sa musí meniť počet medzier na každom riadku. Elastic tabstops sú obyčajné taby (teda vždy 1 tab, o samotné zarovnanie do stĺpcov sa stará editor). Zobrazovanie v konzole / nástrojoch ako diff sa dá poriešiť, ale chýbajúcu podporu v IDE to nevyrieši.

[kralyk z abclinuxu]

Ano, taby se nemaji pouzivat na zarovnavani, ale to bud musite mit inteligentni editor, ktery zvoli spravne taby nebo mezery podle kontextu, nebo se stale hlidat (a sve kolegy) jak zarovnavate.

Třeba v Qt Creatoru tohle afaik není problém... Vůbec mi to celkově nepřijde jako problém, zarovnává se typicky mnohem méně často než odsazuje.

[Odin1918]

Jak to prosim java narizuje? Nemam pocit, ze by sun nebo oracle vydal nejaky zavazny coding style. Mozna se pomery zmenily, uz se programovanim dost roku nezabyvam, ale tenkrat bylo zavazne to, co chtel zakaznik ci zamestnavatel, a pokud mne pamet neklame, v drtive vetsine coding style zahrnoval odsazovani tabulatory.

[xkucf03]

Nenařizuje. Spíš mi přijde, že převažují tabulátory. Na současném projektu máme dvě mezery, jinde to byly čtyři, nebo zase tabulátory. Když o tom rozhoduji já, tak tabulátory. Ve standardní knihovně to není jednotné, někde jsou tabulátory, někde čtyři mezery.

[Odin1918]

Je mi jasne, ze toto nelze naridit. Ani jsem o zadne doporuceni od uvedenych firem neslysel. Kazdopadne dekuji za postreh o std knihovne.

[radix]

Zadny "zavazny" coding style samozrejme neexistuje a neni vynutitelny.

Psal jsem jen o sirce odsazeni - 4 mezery. To muze byt realizovatelne bud 4 mezerami nebo nastavenim tabulatoru na sirku 4 mezery.

[Odin1918]

To, ze to neni zavazne, mi bylo jasne. Imho je nejlepsi pouzit tabulator a kazdy, at si nastavi kolika mezerami jej chce zonrazovat.

[pavlix]

Souhlasím s tím, že je důležitý především počet odsazení, který vyjadřuje zanoření, ne zda je realizován mezerami nebo taby. Osobně vidím úplně odlišný problém a to, že se používají znaky, které mají i jiný účel než odsazení zanořených bloků, především pak k různému dalšímu zarovnávání. Za teoreticky nejsprávnější bych považoval samostatný znak používaný výhradně na odsazení prvků bloku. Tabulátor se zdá jako přijatelná náhrada, ale reálná zkušenost mě donutila používat mezery všude, kde to jde.

Osobně mám největší problémy právě se všemožným zarovnáváním, které je buď důsledkem (1) umělého lámání řádků za účelem jejich zkrácení, nebo (2) dlouhým konstrukcím bez blokové struktury.

Každý způsob formátování, který nelze triviálně implementovat v editorech, je podle mého názoru debilní. Stejnětak mi přijde debilní každý způsob formátování, kde změna v jednom řádku nebo třeba jen v názvu identifikátoru implikuje změnu v několika dalších řádcích. Ale to se bohužel týká drtivé většiny projektů, se kterými se setkávám.

gboolean
nm_platform_link_get_driver_info (NMPlatform *self,
                                  int ifindex,
                                  char **out_driver_name,
                                  char **out_driver_version,
                                  char **out_fw_version)
{

Výše uvedený kousek je z NetworkManageru, který ve stylu následuje glib/gobject. V případě změny názvu funkce například na nm_platform_link_get_driver_details znamená změnu v následujících čtyřech řádcích, která (1) musí být provedena ručně nebo pomocí search&replace v bloku složeném z těch čtyř řádků a (2) projeví se v diffech a gitovské historii.

  if (service && service[0])
    {
      char *c;
      gaih_service.name = service;
      gaih_service.num = strtoul (gaih_service.name, &c, 10);
      if (*c != '\0')
»·······{
»·······  if (hints->ai_flags & AI_NUMERICSERV)
»·······    {
»·······      __free_in6ai (in6ai);
»·······      return EAI_NONAME;
»·······    }

»·······  gaih_service.num = -1;
»·······}

      pservice = &gaih_service;
    }

Tenhle kousek je naopak z glibc a představuje podle mě nejidiotštější možnou kombinaci použití tabulátorů a mezer. Formátování dává smysl pouze při pevně definované šířce tabulátorů a tudíž sdílí nevýhody obou přístupů. Nemluvě o tom, že tento styl disponuje dalšími debilitami jako je postupné dvojté odsazení kvůli jedné konstrukci (odsazená složená závorka pod ifem a následně odsazený i její obsah).

A abych se nedržel jenom céčka, pythonisti budou možná oponovat, že mají toto vyřešené, ale ani náhodou. Zatímco příkazy se v pythonu píšou většinou do řádků a odsazují podle příslušnosti k bloku, literály datových strukturu fungují stejně blbě jako v céčku.

def week_days():
    return [
        'Monday',
        'Tuesday',
        'Wednesday',
        'Thursday',
        'Friday']

Naštěstí lze poslední hranatou závorku odložit na další řádek a přidat nepovinnou čárku, čímž se seznam stane daleko lépe editovatelným (každý datový řádek je pak rovnocenný), ale i tak to má k dokonalosti ještě daleko.

A pak jsou tu takové klasiky jako céčkovský switch, který se sice používá na větvení na více větví kódu, ale ve skutečnosti neobsahuje bloky.

switch {
case 0:
     do_something();
     break;
default:
     do_something_else();
}

A to nemluvím o různých XML, kde se whitespace považuje za strukturní nástroj i za data, ale tyto dvě věci nejsou udržovány v harmonii jako třeba u pythonu, takže jakákoli snaha napsat kód hezky prosakuje bohužel i do dat.

Mně z toho plyne jediná věc. Lidé prasí, protože prasit chtějí, protože je čistota struktury prostě nezajímá. Těch pár lidí se smyslem pro logickou strukturu a dokonalost to nezachrání a i ti se snaží vše přiohýbat svým zkušenostem a zvyklostem.

[Bedňa]

Všetko okrem:

nm_platform_link_get_driver_info (NMPlatform *self, int ifindex, char **out_driver_name, char **out_driver_ version, char **out_fw_version)
{
	// code
}

nepokladám za pekné a aj pri svojom malom rozlíšení monitoru vidím celý riadok.

Občas používam aj takýto zápis ale to skôr v spojení s DB, tam býva aj veľký počet položiek:

nm_platform_link_get_driver_info (
	NMPlatform *self,
	int ifindex,
	char **out_
	driver_name,
	char **out_driver_version,
	char **out_fw_version
) {
	// code
}

Pri takýchto zápisoch a použití tabulátorov nemám žiadny problém.

[mirec]

Používam prakticky rovnaký štýl. Ľudia majú často tendenciu zarovnávať to na otváraciu zátvorku, čo robí bordel vo VCS ak sa náhodou zmení názov funkcie (musí sa meniť celé zarovnanie), alebo nebodaj niekto refaktoruje kód automaticky a na x miestach sa mu rozbije zarovnanie. Podľa mňa je tento kód prakticky rovnako čitateľný ako kód zarovnaný nazátvorku. A ešte pozor problematické je len takéto zarovnávanie, ak niekto zarovnáva napríklad na znak = tak to nijako nepokazí odsadenie (to je len po prvý nebiely znak).

[pavlix]

Abych nezapomněl, tady to byla deklarace/definice té funkce, což se dá v podstatě dělat jednoduše podle konvencí. Horší je, když chceš tu funkci zavolat v rámci nějaké konstrukce.

[pavlix]

Ľudia majú často tendenciu zarovnávať to na otváraciu zátvorku

Jak jsem psal, je to debilita, ale ve spoustě projektů se na tom trvá i pro nový kód.

A ešte pozor problematické je len takéto zarovnávanie, ak niekto zarovnáva napríklad na znak = tak to nijako nepokazí odsadenie (to je len po prvý nebiely znak).

WTF?

[mirec]

Jak jsem psal, je to debilita, ale ve spoustě projektů se na tom trvá i pro nový kód.

Mnoho ľudí žije v minulosti. Práve preto sa v blogu zamýšľam, či nie je na čase trochu aktualizovať konvencie. Argumentovať dnes, že niekto povedal že x je lepšie než y je tak isto blbosť, hlavne ak niekto ťahá do siskusie Guida, ktorý má iný názor, ale podriadil sa väčšine.

| ->int a...... = 7;
| ->int wtf.... = 6;
| ->int odpoved = 42;

Odsadenie tabom mi neovplyvní zarovnanie na znak "=". Stačí dodržať jednoduché pravidlo: taby po prvý nebiely znak. Zvyšok môže byť zarovnaný, ale zarovnávať v takom prípade len medzerami (ale to je hádam samozrejmosť, predpokladám, že kto sa naučil programovať by sa mal naučiť ovládať aj editor).

[pavlix]

Jo aha, tohle zarovnání na rovnítko. To je taky hrozná debilita a to úplně ze stejných důvodů jako na závorku.

--- a   2015-11-22 10:03:43.920460232 +0100
+++ b   2015-11-22 10:04:01.180460038 +0100
@@ -1,4 +1,5 @@
-alpha = 12
-beta  = 78
-gamma = 25
-delta = 17
+alpha   = 12
+beta    = 78
+gamma   = 25
+delta   = 17
+epsilon = 1

Triviální úprava vede zase na (1) rozbití diffů a (2) nutnost ruční editace, pokud člověk nemá nějaký specializovaný editor, který zrovna tohle umí. Přitom je to úplně zbytečné, člověk ty hodnoty bez problémů přečte i bez zarovnání.

--- a   2015-11-22 10:05:36.190458970 +0100
+++ b   2015-11-22 10:06:06.290458632 +0100
@@ -2,3 +2,4 @@
 beta = 78
 gamma = 25
 delta = 17
+epsilon = 1

Kvůli těmhle jalovým nápadů se pak člověk týdny hádá, jestli je jeho patch dostatečně minimální nebo měsíce čeká, než se někdo odhodlá reviewovat patch s padesáti změnami z nichž čtyři jsou funkční a čtyřicet šest je jen z důvodu debilního formátování.

[mirec]

Ja som to kedysi používal a potom som zistil čo za bordel mi to robí vo VCS. Zašiel som dokonca až do toho štádia keď do zoznamov, slovníkov ... dávam vždy (okrem javascriptu, niektoré browsery s tým majú problém) za posledný prvok oddeľovač aby sa pri pridaní položky nemenili 2 riadky.

Inak keď tak ľudia chcú zarovnávať nechápem prečo sa nerozšírilo napr. elastic tabstops. Implementačne je to jednoduché a rieši to krásne problém zo zarovnávaním bez toho aby to robilo problémy vo VCS.

[pavlix]

Ja som to kedysi používal a potom som zistil čo za bordel mi to robí vo VCS. Zašiel som dokonca až do toho štádia keď do zoznamov, slovníkov ... dávam vždy (okrem javascriptu, niektoré browsery s tým majú problém) za posledný prvok oddeľovač aby sa pri pridaní položky nemenili 2 riadky.

Tak. Celý princip oddělovače je u víceřádkových konstrukcí špatně. Viz třeba příkazy v Pascalu versus C.

function moje_funkce(a: integer; b: real)
begin
    do_something;
    do_something_else;
    do_something_different
end

S oddělovači jsou při víceřádkovém zápisu pořád jenom nějaké problémy. Python naštěstí umožňuje nadbytečné čárky dle specifikace. Céčko myslím jen v konkrétních dialektech.

Ty elastic tab stops mi ale taky přijdou nedomyšlené. Na ty nejjednodušší účely to pomůže a bylo by fajn to vidět implementované, i když to nebude fungovat na to, jak se v současné době taby běžně používají. Problém ale vidím v tom, že se člověk bude muset zcela podřídit přesnému formátování a neprokládat související řádky ničím jiným, což u mezer nebo mixu nebyl problém.

I kdyby byly elastic tabs stoprocentním řešení, prosadit je by bylo na dlouhé lokte, ale vzhledem k tomu, že to tak není, to vidím dost bledě.

[xkucf03]

Příloha:

• jedit - elastické tabulátory.png (4154 bytů)

neprokládat související řádky ničím jiným, což u mezer nebo mixu nebyl problém.

jj, nefunguje to – v příloze je ukázka z jEditu.

Když je to proložené komentářem, tak to zarovnání stejně dost ztrácí smysl. Ale je fakt, že aspoň prázdné řádky by to tolerovat mohlo.

[mirec]

Elastické tabulátory nie sú strieorná guľka.

Ale je fakt, že aspoň prázdné řádky by to tolerovat mohlo.

To práve nesmie, neexistoval by spôsob ako rozdeliť skupiny, ktoré majú byť rovnako odsadené.

[xkucf03]

Souhlasím, taky jsem proti zarovnávání¹²³ – ovšem tím padá asi jediný argument pro použití mezer – pravidla jsou pak tak jednoduchá, že je dokáže dodržovat i polodementní opice (stačí si nastavit editor/IDE, aby klávesa TAB vkládala jeden tabulátor).

_{[1] když už potřebuji napsat každý parametr funkce nebo hodnotu v poli na jiný řádek, tak to odsadím o úroveň, nebudu to zarovnávat na nějaký znak nad tím
[2] zarovnávat na rovnítko sice může na první pohled vypadat dobře, ale kvůli verzovacím systémům je to zlo
[3] zajímavou alternativou jsou elastické tabulátory}

[pavlix]

ovšem tím padá asi jediný argument pro použití mezer

To se ale bavíme čistě hypoteticky, že. Realita je taková, že pro použití mezer bude vždy a za všech okolností platit ten jeden velký a zásadní důvod, že tím nevzniká takový bordel jako při mixování tabů a mezer. A vzhledem k tomu, že používání tabů nutně v části případů vede na jejich mixování s mezerami, jsi opět v háji.

[xkucf03]

Realita je taková, že pro použití mezer bude vždy a za všech okolností platit ten jeden velký a zásadní důvod, že tím nevzniká takový bordel jako při mixování tabů a mezer.

O jakém mixování mluvíš? V předchozím komentáři jsme se shodli na tom, že zarovnávat se nebude. Bude se tedy jen odsazovat. Pak můžou nastat následující situace:

• používáme tabulátory + někdo si nastaví odsazování mezerami → problém
• používáme mezery + někdo si nastaví odsazování tabulátory → problém
• používáme mezery + někdo si nastaví odsazování jiným počtem mezer → problém

Když lidé nedodržují pravidla, bude to špatně ať nastavíš konvence tak nebo tak. Aktuální příklad z praxe: používáme odsazení pomocí mezer (to se mi nelíbí, ale respektuji to) a někdo tam pošle tabulátory – ničeho si nevšimne, protože u něj to vypadá stejně – a máme ve zdrojácích bordel. Závěr: konvence odsazovat mezerami problém neodstranila.

A vzhledem k tomu, že používání tabů nutně v části případů vede na jejich mixování s mezerami, jsi opět v háji.

Nutné je to jen při zarovnávání – pak je potřeba mít dobré IDE/editor nebo si s tím dát ruční práci. Pokud nezarovnáváš, tak k žádnému mixování nedochází.

[pavlix]

O jakém mixování mluvíš?

O tom, které se objevuje v reálných projektech bez ohledu na to, na čem se my shodnem.

Když lidé nedodržují pravidla, bude to špatně ať nastavíš konvence tak nebo tak.

Opět perfektní použití čisté logiky bez ohledu na realitu. V jednoduchosti je síla. Nepoužívání tabů lze lehce vysvětlit i kontrolovat.

[mirec]

Nepoužívání tabů lze lehce vysvětlit i kontrolovat.

Dobre, dohodneme sa na nepoužívaní tabu. Čo ďalej. Každý si bude odsadzovať 2 medzerami? 4 medzerami? 8 medzerami? Rozoznáte rozdiel medzi 8 a 7 medzerami ak niekto povedzme zle skopíruje riadok? Ja rozdiel medzi 1 a 2 úrovňami odadenia spoznám ľahko ale rozdiel o 1/8 úrovne odsadenia nespoznám.

[pavlix]

Dobre, dohodneme sa na nepoužívaní tabu. Čo ďalej. Každý si bude odsadzovať 2 medzerami? 4 medzerami? 8 medzerami?

Ale já rozumím výhodám odsazování jediným znakem, který se roztáhne na několik pozic, psal jsem to už v prvním příspěvku.

Rozoznáte rozdiel medzi 8 a 7 medzerami ak niekto povedzme zle skopíruje riadok?

Ano, poznám. Ale ve zdrojácích třeba glibc je vidět, že ho zjevně nepoznají všichni.

[xkucf03]

Jak jsem psal výše – na problémy narazíš i když máš jako konvenci mezery. Mezery tedy nic neřeší. Tu konvenci respektuji jen kvůli tomu, že je s mezerami napsaná hromada kódu, přepsat ho nejde a nutit lidi v jednom týmu se přepínat mezi mezerami a tabulátory je taky nesmysl.

V jednoduchosti je síla. Nepoužívání tabů lze lehce vysvětlit i kontrolovat.

Vysvětlit to jde úplně stejně. Nastavit v IDE/editoru taky. Vynutit nepoužívání mezer pro odsazení rovněž.

[pavlix]

Vysvětlit to jde úplně stejně.

A teď tu o karkulce.

[mirec]

Inak taká drobnosť ktorá sa hodí pri prepínaní medzi projektmi: editorconfig. Odporúčam to hodiť do existujúcich projektov, niektoré editory sa podľa toho riadia.

[pavlix]

To nevypadá zle. Nevěděl jsem, že existuje něco použitelného napříč tolika editory včetně vimu.

[Josef Kufner]

To vypadá velice pěkně. Škoda, že to víc neřeší i způsoby formátování kódu, jako třeba kde mají být závorky a podobně.

[hypvofxy]

Parada, diky za tip. Koukam, ze IntelliJ to zvlada nativne a existuji i pluginy pro NetBeans a Eclipse, takze pro Javu to vypada velmi pouzitelne.

[Bedňa]

Píšeš podobne ako ja, to som si všimol. Hovorím si, že mi tu niečo chýba a ono tento rok tu nieje anketa

[mirec]

Medzi doplnenými linkmi je celkom zaujímavá anketa na stackoverflow.

[pavlix]

nepokladám za pekné a aj pri svojom malom rozlíšení monitoru vidím celý riadok.

To byl jen příklad, spousta funckí má daleko delší seznam argumentů, zvlášť pokud se jedná o struktury s prefixovaným tagem. Ve skutečnosti se ti některé na řádek vejdou a jiné nikoliv. Co víc, ve skutečnosti se ti někdy vejdou a někdy ne ve stejném monitoru, já například dost často edituju dvojici souborů vedle sebe a tím máš prostor na zobrazení řádku z ničehonic poloviční.

Já osobně používám většinou to co mi nabízí vim, tedy seznam argumentů tak, jak to máš ty, ale s dvojtým odsazením (tedy dvojnásobným počtem mezer, na příkladu glibc pochopíš, proč taby zásadně nepoužívám).

[Bedňa]

Tak občas sa teba prispôsobiť, ale keď sa nemusím dávam taby ako som písal.

[xsubway]

Nebudu se vyjadřovat k tomu, jestli je důležité zarovnávat dvěma, třemi nebo N mezerami/tabulátory. Jsem si ale naprosto jistý, že pokud pracuje na projektu více programátorů a některý z nich se rozhodne při malé úpravě naformátovat celý zdrojový kód, tak je to na červenou kartu.

[pavlix]

Správné je napsat vždy celý modul odznovu a starý zahodit. Proti tomu nikdo nemůže říct ani popel. :)

[xsubway]

Ano, ale jen pokud je ten modul skutečně nový. Setkávám se s tím, že chci zjistit, proč v nějakém projektu v jednom souboru změnil jeden řádek a zjistím, že v revizi je změněno tisíc a jeden řádek jen proto, že se někomu nezamlouvalo formátování :|

[pavlix]

Ano, ale jen pokud je ten modul skutečně nový.

Pobavilo. Myslím, že ti unikla pointa příspěvku.

[Miloslav Ponkrác]

Nevýhody tabelátorů, které se nikdy nezredukují, jsou ty, že jsou bílým znakem – a tudíž je lidé nevidí a dělají v jejich použití chyby.

Proto ve svých zdrojových kódech mám pouze mezery, pokud tabelátory nevyžaduje code style projektu, na kterém dělám, tedy nikdy je nepoužívám dobrovolně.

v ASCII má te celou škálu znaků, které můžete používat, máte-li masochistické sklony. Například vaší pozornosti bych dal znaky s kódem 0x1C–0x1F, což jsou 4 druhy informačních oddělovačů, kterými si své zdrojové kódy zcela jistě vyšperkujete dokonaleji a sofistikovaněji, než pouhým tabelátorem. (konec sarkasmu)

Mimochodem, proč zůstávat na úrovni odsazování v řádku pomocí znaku 0x9? Proč neodsazovat i řádkově pomocí znaku 0xB? Můžete tak odsazovat důležité části kódu vertiálně a označovat tak důležité bloky. (konec dalšího sarkasmu)

A to nemluvím o dalších bílých znacích a kontrolních kódech, které nabízí Unicode!!! To jsou teprve možnosti. (konec dalšího sarkasmu)

Používání tabelátoru ve zdrojových kódech je jen jedna z možností, jak si zkomplikovat život.

Když už jste masochisté s tabelátory, využívejte alespoň pořádně celou ASCII, je tam mnohem více užitečnějších znaků. A co teprve v Unicode, pokud píšete v UTF-8! Tam najdete věcí v kontrolních a bílých znacích, co můžete použít přímo ve zdrojovém kódu!

Chápu, že byly doby, kdy každý bajt se počítal, a pak kombinace mezery s tabelátory byla jakási forma komprese textu. Dnes už je ale opravdu jedno, jestli má zdrojový soubor 12340 bajtů nebo 12341 bajtů, to už nikoho netrápí.

Zkrátka nevidím jediný důvod, proč tabelátory ve zdrojovém souboru vůbec používat. A pokud je používáte a nepoužíváte ty další bílé znaky, tak jste rasisté a dogmatici – prostě jen pokračujete v obdobě Y2K z doby, kdy každý bajt navíc byl problém.

Miloslav Ponkrác

[mirec]

Nevýhody tabelátorů, které se nikdy nezredukují, jsou ty, že jsou bílým znakem – a tudíž je lidé nevidí a dělají v jejich použití chyby.

Nevýhody mezer, které se nikdy nezredukují, jsou ty, že jsou bílým znakem – a tudíž je lidé nevidí a dělají v jejich použití chyby.

v Unicode má te celou škálu znaků, které můžete používat, máte-li masochistické sklony. Například vaší pozornosti bych dal znaky s kódem U+00A0, U+2000-U+200B ...

[pavlix]

Nevýhody mezer, které se nikdy nezredukují, jsou ty, že jsou bílým znakem – a tudíž je lidé nevidí a dělají v jejich použití chyby.

Nesmysl. Mezery sice jsou bílé znaky, ale při absenci tabulátorů a při použití neproporcionálního písma jsou na první pohled vidět (pokud nejsou na konci řádku).

[mirec]

Nesmysl. Mezery sice jsou bílé znaky, ale při absenci tabulátorů a při použití neproporcionálního písma jsou na první pohled vidět (pokud nejsou na konci řádku).

Nesmysl. Tabulátory sice jsou bílé znaky, ale při absenci mezer a při použití libovolného písma jsou na první pohled vidět (pokud nejsou na konci řádku).

[xkucf03]

Nesmysl. Tabulátory sice jsou bílé znaky, ale při absenci mezer a při použití neproporcionálního písma jsou na první pohled vidět (pokud nejsou na konci řádku).

[pavlix]

Čekal jsem, kdo se chytí. Ale stejně mě to pobavilo.

[pc2005]

Jako někdo, kdo dostal do vanilky pár patchů, je styl kódu jasnej: tabulátory o renderovací délce 4 znaky. Všechno ostatní je hereze a správci subsystémů to daj značně najevo .

Jinak v mejch zdrojácích odsazuju dvouznakovým tabem nebo naprosto chaoticky (například copypaste z MC vieweru nahradí všechno mezerama) + různé kopírování kusů kódu z různých lokací v různý čas.

P.S. Parser, co má v sobě pravidla pro formátování textu je to blobovatej :-P .

[mirec]

Renderovacia dĺžka je 8, nie 4.

[pc2005]

Kruci, no už jsou to tak dva měsíce a po úspěchu jsem si to zase nastavil na 4. Mea culpa.

[Miloslav Ponkrác]

Renderovací délka je podle toho, jak si jí člověk nastaví. Od toho jsou to tabelátory, tedy pro dělání tabulek na psacím stroji.

Takže když si zvolíte renderovací schéma, že tabelátory budou zarovnávány na pozice sloupců 10, 40, 830 a 2260 a od 5. tabelátoru nahoru na nejbližší vyšší násobky 100, je to zcela v pořádku jako renderovací schéma tabelátoru. V proporcionálních dokumentech jsou pak zarovnávky definovány třeba v centimetrech, kam posunou začátek dalšího textu.

Dokonce můžete do dokumentu nahrát pomocí znaků s kódu 0x88 a 0x89 vaše pozice tabelátorů. Pokud pozice tabelátorů nahrajete pomocí těchto znaků do dokumentu, je dokument, který dodržuje standardy povinen tyto pozice dodržovat (platí v unicode).

Nicméně jak už jsem napsal, tabelátory ve zdrojových kódech je přežitek z dob, kdy každý bajt navíc byl problém vzhledem k malým úložištím. A také z doby, kdy nekompatibilita dokumentů nebyl problém, který by někoho moc zajímal.

Jak píši, chce-li někdo dnes opakovat schémata z roku 1970, prosím. Klidně i ty tabelátory – každému soudruhu podle jeho gusta. Jsou mezi námi různí lidé s různými sexuálními preferencemi, a není důvod, proč masochistům zabraňovat v jejich realizaci.

Kromě masochismu, či dogmatismu převzatého z roku 1970, kdy počítače měly třeba 8 KB RAM a ukládalo se na děrné štítky, takže zkrácení pomocí tabelátoru znamenalo o něco míň štípání kleštičkami a oddálení syndromu karpálního tunelu – považuji používání v neproporcionálním textu tabelátorů za hloupost a sebezohavování se.

Píšu to takto tvrdě, protože článek jede tvrdě opačně.

Nevidím žádný důvod, proč v neproporciolnálním zdrojovém kódu mít jakýkoli tabelátor. Kromě menšin se změněnou sexuální preferencí, jak už jsem psal výše.

[xsubway]

Je skvělé, když má projekt určený a (hlavně) dodržovaný coding style. (Taby mají výhodu v osobním nastavení - renderování na 4 znaky - ale vždy to nefunguje, na odkazované stránce se taby v prohlížeči renderují na 8 znaků ...)

[pavlix]

Je skvělé, když má projekt určený a (hlavně) dodržovaný coding style.

Existuje nějaký takový open source projekt netriviálního rozsahu? Já narážím na to, že je coding style nedodržovaný, neúplný a nejednoznačný. :)

[xsubway]

To bylo spíš takové zbožné přání ... ale předpokládám, že Linux bude jeden z takových.

Mám zkušenost s closed source projekty (netriviálního rozsahu), kde je coding style sice určený, ale bohužel ne vždy dodržovaný

Open source používám na každém kroku, ale nevytvářím do něj žádné zdrojové kódy. Nicméně občas se do takového zdrojáku musím podívat .-)

[pavlix]

ale předpokládám, že Linux bude jeden z takových.

Neptal jsem se na zbožná přání a předpoklady. :)

Mám zkušenost s closed source projekty (netriviálního rozsahu), kde je coding style sice určený, ale bohužel ne vždy dodržovaný

Motivace pro nedodržování coding style je příliš veliká. :)

[Miloslav Ponkrác]

Pokud není motivace pro dodržování nějakého code style, je to obvykle proto, že code style je špatně zvoleno. Obvykle code style je zvoleno tak, že si nějaký vedoucí rozhodně vyzkoušet svoji moc nad těmi programátory a neovládnuté ego pak vyplodí něco nepraktického. A pak je na to kašláno.

Lidé ochotněji dodržují pravidla, která mají smysl, než ta, která jsou evidentně prodlužováním penisů vedoucích. Což se v code style děje moc často.

[pavlix]

Pokud není motivace pro dodržování nějakého code style, je to obvykle proto, že code style je špatně zvoleno.

Každý coding style, co jsem kdy viděl, měl nějakou zásadní vadu. Navíc jsem narazil na výrazný rozdíl na jednotlivé body mezi lidmi. Tudíž je prakticky každý coding style z pohledu prakticky každého vývojáře špatně zvolený a tudíž jenom jinými slovy říkáte to co já, tedy že (univerzálně) není motivace pro dodržování coding style.

[Michal Kubeček]

V té úvaze je chyba v předpokladu, že to, že se mi na coding style něco nelíbí, automaticky znamená, že nemám motivaci ho dodržovat. Mně se třeba některé body coding style linuxového jádra vůbec nelíbí (třeba ty tabulátory), ale přesto mám silnou motivaci ho dodržovat, např. proto, že to, jak důsledně je dodržován v net/, mi dost často ušetří práci (třeba proto, že se můžu spolehnout, že určité konstrukce budou zapsány určitým způsobem).

[pavlix]

V té úvaze je chyba v předpokladu, že to, že se mi na coding style něco nelíbí, automaticky znamená, že nemám motivaci ho dodržovat.

To už si ovšem vyřešte s mistrem Ponkrácem.

[Miloslav Ponkrác]

Takže mistr Michal Kubeček a pavlix neumějí chápat psaný text. To je odpověď mistra Ponkráce. Zbytek viz odpověď níže.

[Michal Kubeček]

Nabídka zní lákavě, ale jsou zkušenosti, které si radši nechám ujít. :-)

[Miloslav Ponkrác]

Já jsem ale nepsal nic o líbení se / nelíbení se v rámci coding style. O tom v mém příspěvku nenajdete ani slovo.

Já jsem psal o dobře zvoleném code style, a vůbec nic o líbivém code style.

[Michal Kubeček]

To bylo spíš takové zbožné přání ... ale předpokládám, že Linux bude jeden z takových.

Stoprocentně samozřejmě ne, to by se u projektu takového rozsahu asi uhlídat nedalo, ale míra dodržování coding style je - aspoň u core částí - hodně nadstandardní. V nějakých driverech exotických zařízení, které si píše výrobce sám a nikdo jiný jim nerozumí, tam se občas najde ledacos podivného, a to nejen ohledně coding style.

[Michal Kubeček]

Mimochodem, když už tu byla řeč o dalších bílých znacích, ve zdrojácích SCSI tape driveru jsem narazil i na form feed. :-)

[pc2005]

Jo u takhle starých driverů jsou dost zajímavý věci. Třeba takovej driver disketovky by dneska určitě neprošel (bez ohledu na to, že se diskety už ani snad nevyráběj).

[R]

Driver disketovky (drivers/block/floppy.c) je v pohode, vacsina chyb, co najde "scripts/checkpatch.pl -f" je vo formatovani tabuliek. Ale ked sa tie tabulky pozries v editore, tak vyzeraju pekne prehladne - to ma v tomto pripade vyssiu prioritu.

Horsie su na tom stare SCSI drivery...

[Michal Kubeček]

U toho st.c jsem měl neodbytný pocit, že nezanedbatelná část z něj je starší než Linux.

[pc2005]

floppy.c: Copyright (C) 1991, 1992 Linus Torvalds st.c: Copyright 1992 - 2010 Kai Makisara

Ale myslím, že jsou na tom podobně . Například aic7770.c: "$FreeBSD$".

[pc2005]

total: 337 errors, 49 warnings, 4645 lines checked

Ale pro nepřijetí patche stačí někdy i jeden warning.

Ale checkpatch i když obsahuje mnoho testů, tak některé programovací věci nedává. Třeba ten floppy.c je plnej globálních proměnných (dneska se to dává někam do pdata). Makra jsou mixovaný s kódem (případ i toho st.c). Blokování částí zdrojáku ifdef makry. Podivné definice init a exit funkcí (které se dneska už ani nepoužívaj ). Globální ioctl zámek se řeší tak, že se zavolá funkce, ve které je wrapper s mutexy a ta pak volá původní kód . Ještě myslím, že když se během práce s disketou vytáhne disketa, tak se driver zasekne (naposled to dělalo win3.11 s modrou smrtí).

[hypvofxy]

Jeste jsem si vzpomnel na oficialni pruzkum na StackOverflow. Konkretne:

After millennia of heated debate, mercifully, at long last, we have an answer. Most developers prefer tabs to spaces.

Upon closer examination of the data, a trend emerges: Developers increasingly prefer spaces as they gain experience. Stack Overflow reputation correlates with a preference for spaces, too: users who have 10,000 rep or more prefer spaces to tabs at a ratio of 3 to 1.

[mirec]

Doplnené.

[Bystroushaak]

Příloha:

• messy_shit.png (78593 bytů)

Osobně používám mezery prostě proto, že je to PEP8 standard. Dřív jsem používal taby, ale v práci jsme se domluvili na používání PEP8, tak používám PEP8.

Ke kontrole používám 3 lintery v editoru, které mi neustále scannují kód a upozorňují na možné prohřešky. Jmenovitě PEP8, pylint a pyflakes. Pak z toho mám skoro infarkt, když otevřu nějaké bukkake v pythonu, kde autor nepoužil nic z běžných rozumných konvencí (viz příloha).

[Miloslav Ponkrác]

A to je hlavní argument pro používání mezer. Čím složitější code style si vymyslíte, tím pravděpodobněji nebude dodržován.

Jestliže někdo začne vymýšlet, jak používat tabelátory s mezerami a pro ně složitá pravidla pro odsazování, významně code style zahustíte blbostmi, které navíc v editorech často nevidíte – a začnou to lidé kurvit.

Základní pravidlo pro zdrojáky je: udělejte to tak jednoduché, aby to byl schopen používat a dodržovat i člověk se 4 promilemi ethanolu v krvi a nedělal v tom chyby.

Tabelátory to nebudou, protože ty od mezer s jistotou ve většině editorů nerozlišíte od mezery ani za střízliva.

Cílem code style je udržovatelnost a čitelnost zdrojových kódů, nikoli dělat text inteligence a vymýšlet novou instanci ezoterického jazyka Whitespace (https://cs.wikipedia.org/wiki/Whitespace).

Jednoduchá pravidla budou spíše dodržována. Jakoby nestačil make jako dostatečně odstrašující příklad.

[Ahmed the Clock Kid]

Psy vs mačky
Tabulátory vs medzery
Si osamelý? Nemáš sa s kým porozprávať?

[mirec]

Si osamelý?

Nie dosť.

[mirec]

Teda no kašlať na to, aj tak za mnou práve letí návšteva takže sa mi neoplatí púšťať sa do ďalších vecí v projekte ktorý robím tak rozpíšem ...

Tento blog som mal rozpísaný od roku 2012 ale akurát tam niečo podobné napísal bedňa tak som to kompostoval.

Predchádzajúci blog ... no to bola kombinácia pár udalostí z predchádzajúcich dní a neustále štekajúceho susedovho psa.

[mirec]

Čo som komu urobil? Dnes sa zase musím hrabať v zdrojáku kde autori nemali jasné, či používajú 2, 4 alebo 3 medzery tak je to všetko namixované.

[Hanna]

Niektorí to robia a je to legitímny príklad v ktorom sa stratí sémantická hodnota pri konverzii 192.168.1.1 192.168.1.1 192.168.1.1 192.168.1.1