Medzery vs tabulátory po siedmich rokoch (diskuse)

[chrono]

Napr. v HTML používam vždy len tabulátory; v C zvyčajne tiež tabulátory, v Python takmer vždy 4 medzery... :)

[Franta]

O tomhle byl nedávno flame na Rootu, takže jen stručně:

1. Tabulátor nese sémantickou hodnotu (počet úrovní odsazení bloku), shluk mezer neříká nic – potřebujeme ještě někde bokem sdělit informaci „kolik mezer = jedno odsazení“.
2. Tabulátory také umožňují, aby si to každý zobrazil, jak mu to vyhovuje – někdo potřebuje větší odsazení, někdo menší, tak si podle toho nastaví editor, ale v souboru je to uložené vždy stejně (jeden tabulátor). Já mám např. šířku tabulátoru 4.
3. Míchání mezer a tabulátorů při odsazování je samozřejmě špatně, je potřeba dodržovat konvence daného týmu.
4. Jiná věc je zarovnávání – když už* zarovnáváme, tak mezerami, protože účelem zarovnání není posunout text na X-tou úroveň, ale zarovnat se znaky nad/pod ním.

Příklad:

<objekt>
    <vlastnost-1    hodnota="hodnota 1"/>
    <vlastnost-123  hodnota="hodnota 123"/>
    <vlastnost-9999 hodnota="hodnota 9999"/>
</objekt>

Před <vlastnost… bude tabulátor a před hodnota="… budou mezery.

*) osobně jsem spíš proti zarovnávání, protože při přidání nové (delší) položky je potřeba změnit všechny ostatní řádky a mj. to dělá bordel ve verzovacím systému.

[mirec]

+10, presne o tomto som asi pred 2 rokmi písal blog, ale nedopísal som ;) Veľmi dobre napísané. Škoda, že pythonisti sa dosť fanaticky držia medzier (pep 8).

[FrostyX]

Já se držím odsazování na začátku řádků pomocí tabů a použití mezer při zarovnávání. K zamyšlení doporučím TABs vs Spaces. The end of the debate

[Let_Me_Be]

To ze mezery vypadaji vsude stejne je hlavni nevyhoda.

[Bystroushaak]

Jak kde. Když se dívám na své kódy třeba na githubu, tak bych tam mezery uvítal, protože osmimístné taby to nehorázně roztahují do strany.

[Franta]

To je jeden řádek v CSS, ne? Lepší než přepisovat všechny zdrojáky

[Bystroushaak]

To sice jo, ale vysvětlovat to githubákům se mi nechce :D

[Člověk z Horní Dolní]

To je podobný argumnent jako "můj editor neumí nastavit šířku tabů, proto jsou taby špatný" :)

[Bystroushaak]

Já taby používám.

[Ivorne]

To možná, ale argument "každý editor má nastavené jinak taby, leckde to nejde nastavovat a pořád je v tom bordel" už se mi zdá dostatečný.

To bys musel mít všechny systémy, se kterými pracuješ plně pod kontrolou (a musely by podporovat šířku tabelátoru), což normální člověk většinou nemá.

Práce v editoru a v shellu. V editoru mám kvůli programování tab na šířce 4, v shellu je všude 8 a přenastavit to moc nejde, takže když pracuji v obou najednou, tak jsem v pytli.

[Josef Kufner]

Ono někdo, kdo to s programováním myslí vážně, používá neschopný textový editor?

[xkucf03]

Ale kód (správně) odsazený tabulátory nemá žádný problém s tím, že si každý nastaví jinou šířku – naopak k tomu přímo vybízí a je to jedna z jeho výhod.

Někde to bude třeba:

if (a == 1) {
    System.out.println("a == 1");
    System.exit(0);
} else if (a == 0) {
    System.out.println("a == 0");
    System.exit(1);
}

a jinde:

if (a == 1) {
        System.out.println("a == 1");
        System.exit(0);
} else if (a == 0) {
        System.out.println("a == 0");
        System.exit(1);
}

a formátování se nerozbije, jen se přizpůsobí nastavení daného uživatele.

[Ondrej 'SanTiago' Zajicek]

Rozbije, pokud se tabulatory pouzivaji krome odsazovani bloku i na dalsi odsazeni dodatecneho textu na radce (napr. komentare k radku). A IMHO to je misto, kde je tabulator daleko dulezitejsi nez na odsazeni bloku - spravne odsazeni bloku je mozne bez potizi udrzovat automaticky editorem bez ohledu na to, zda se pouzivaji mezery ci tabulatory, zatimco spravne odsazeni dodatecneho textu na radce asi rozumne udrzovat nejde jinak nez s pouzitim tabulatoru.

[pavlix]

spravne odsazeni dodatecneho textu na radce asi rozumne udrzovat nejde jinak nez s pouzitim tabulatoru.

Vzhledem k tomu, že to nejde ani s použitím tabu, tak je to dost irelevantní.

[Ondrej 'SanTiago' Zajicek]

S pouzitim tabu je udrzovani takoveho odsazeni podstatne mene narocna.

[pavlix]

Nevím, zda „podstatně méně náročné“ je to správné vyjádření pro „pořád to nestojí za nic“.

[Michal Kubeček]

Dvě mezery v C a C++, čtyři v shellu, tabulátor jen tam, kde to vyžaduje coding style - takže poslední dobou většinou tabulátor. :-(

[Franta]

Proč ? K čemu jsou dobré mezery?

[Michal Kubeček]

Už jsem se zúčastnil příliš mnoha diskusí na toto téma, abych si myslel, že další flame něčemu prospěje. Argumenty obou stran už byly prezentovány tolikrát, že nemá smysl plýtvat časem i prostorem na další přehrávání stále stejné diskuse.

[Bystroushaak]

Dlouhou dobu jsem používal mezery, ale pak jsem se během jedné diskuze na IRC nechal přesvědčit k tabulátorům. Přijde mi to čistější.

[bambas]

odsazeni TAB, zarovnani 2-4 mezery :)

[Sten]

+0,75. Odsazení TAB, zarovnání TAB podle odsazení + tolik mezer, na kolik to vyjde

class MyClass
⇥: public MyOtherClass
{
public:
⇥MyClass()
⇥⇥: field(0)
⇥{}

⇥~MyClass();

⇥MyClass& setField(int value,
⇥⍽⍽⍽⍽⍽⍽⍽⍽⍽⍽⍽⍽⍽⍽⍽⍽⍽⍽bool checkIfZero)
⇥{
⇥⇥if (checkIfZero && value == 0) {
⇥⇥⇥throw std::exception("FIeld is not zero");
⇥⇥}
⇥⇥this->field = value;
⇥}


protected:
⇥int field;
};

[disorder]

toto je jedine spravne pouzivanie tabov. keby to dokazali vsetky editory...

[Člověk z Horní Dolní]

Samozřejmě taby, s výjimkou Clojure (protože to je Lisp a Lispy se musí zarovnávat mezerama, aby kód nevypadal hnusně).

Taby, narozdíl od mezer nespojují "co to je" a "jak to vypadá". Podobně jako HTML a CSS. Zakódovat obarvení syntaxe přímo do zdrojáku taky není dobrý nápad.

[Člověk z Horní Dolní]

Btw, v Javě je doporučuji používat auto-formátování, ušetří to spoustu práce.

[JS]

Musim rict, ze ackoli mam Common Lisp celkem rad, Lispovy zpusob zarovnavani mi dost vadi. Prijde mi, ze to odsazeni pak silene rychle narusta, a je to velmi neprehledne.

[Člověk z Horní Dolní]

Naprosto souhlasim, jenom pro ulozeni neceho do promenne se musi zanorit kod... a taky prefixova aritmetika neni uplne prehledna.

Pod nejakym blogem jsi jednou napsal celkem dlouhy komentar, napad na programovaci jazyk (myslim ze neco s transformacemi dat). Nepamatujes si kde to bylo? Posledni dobou me tohle docela zajima :)

[JS]

Zkousel jsem to najit, ale marne. Obavam se, ze to bylo v nejakem nelinuxovem blogu..

[Bystroushaak]

Já se teď potloukám kolem Rebolu, což je místy podivný lisp-like jazyk s rozumnější syntaxí.

[Člověk z Horní Dolní]

Pro co to používáš (hraní / práce)?

[Bystroushaak]

Zatím pro nic, teď se v tom snažím napsat script na zálohu přečtených článků. Je to docela zajímavá hračka, například parser konfiguráků (něco jako .ini) jsem napsal v backus-naurově formě, namísto abych to rozdělil na jednotlivé řádky a ty pak dále zpracovával:

context[
	conf-file-rule: [any[
			newline     |
			_comment    |
			date-header |
			purl
		]
		to end
	]

	white: [#"	" | #" "]
	_comment: [#"#" to newline]
	date-header: [
		#"[" copy parsed-date to #"]" newline (parsed-date: to-date parsed-date)
	]
	purl: [
		[ thru #"	" | thru #" "] copy parsed-url to newline
		(
			parsed-url: to-url trim to-string parsed-url
			print rejoin [parsed-date " : " parsed-url]
		)
	]

	parse/all d conf-file-rule
]

To by mě dřív ani nenapadlo.

Pořád jsem ale nepřišel na to, jestli má smysl se rebol učit, nebo ne :)

[Člověk z Horní Dolní]

Pokud to má přímo vestavěnou podporu pro BNF, tak to je zajímavá vlastnost, to se může občas hodit.

Parsery se taky dobře píšou v jazycích založených na ML, kód vypadá podobně jako BNF, např. parser markdownu v OCaml.

O Rebolu jsem jednou už tuším slyšel, měl jsem toho pocit, že to je jeden z jazyků, které mají několik originálních nápadů, ale v praxi má smysl je používat jenom na relativně malou skupinu problémů :)

[Bystroushaak]

Pokud to má přímo vestavěnou podporu pro BNF, tak to je zajímavá vlastnost, to se může občas hodit.

Jo, parse.

O Rebolu jsem jednou už tuším slyšel, měl jsem toho pocit, že to je jeden z jazyků, které mají několik originálních nápadů, ale v praxi má smysl je používat jenom na relativně malou skupinu problémů :)

No, já už o něm přečetl pár desítek článků a pár knih a pořád nevím, jestli jo, nebo ne :)

[disorder]

bezne sa pouziva dvojznakove odsadenie: 5 urovni = 10 znakov. lisp ta aspon nauci rozdelit si veci do roznych funkcii, ked uz to nedokazali ine jazyky.

[JS]

Tak to delam taky. Coz o to, delit veci do funkci bych se potreboval naucit (ja mam v podstate tendenci tvorit novou funkci jen v pripade, ze ji volam z vice mist, coz neni idealni).

Ale i tak je to problem, a nejhorsi je to prave na tech operatorech, jak zminuje BzHD vyse. Aritmeticky vyraz pak vypada jako rozsypany caj. Ale ono staci napsat let, if, progn a jste hned v pulce stranky.

[disorder]

ale musis mat pre cely projekt striktne nefinovane ako ma tab vyzerat, lebo pride blbec z horni dolni a zacne mi to pretekat za okraj...

[disorder]

s/nefinovane/definovane/

ja uz dnes nic nenapisem bez preklepu...

[Jan]

Tabulátor mám stále rád, hlavně v asembleru, protože tam si to píšu všechno sám od začátku, takže je to aspoň konzistentní :)

[disorder]

presiel som na ciste medzery a zacinam mat rad python kvoli whitespacu. nie pretoze to je dobre riesenie, ale pretoze exituju ostatni ludia s prijebanymi editormi.

[disorder]

s/exituju/existuju/

[mirec]

V súčasnosti je až neuveriteľné ako niektoré editory dokážu robiť bordel v kóde. U x-ročných vykopávok ako emacs / vim nie je problém nakonfigurovať zobrazovanie tabov, zvýraznenie zlého mixovania tabov a medzier ... Ale komerčné produkty, v ktorých robia kolegovia ... to je jedna veľká katastrofa.

[:::]

Kdyz uz se tady diskutuje odsazeni tak bych mel dotaz na pribuzny tema: Jakym zpusobem formatujete switch v c/c++ pokud se v nem deklaruje promenna a je potreba cely case dat do {}?

Nejak se me nedari prijit na zpusob jak to nejak inteligentne naformatovat aby to vypadalo dobre i pri zmene velikosti tabu.

Jinak switch formatuju takhle:

>-------switch(x) {
>-------case 1:
>------->-------q();
>------->-------...
>-------case 2:
>------->-------x
>------->-------y
>------->-------...
>-------}

V podstate me napadaji 2 reseni, ktere ale obe zbytecne pridavaji uroven zanoreni:

1:

>-------switch(x) {
>------->-------case 1: {
>------->------->-------int a;
>------->------->-------qwe
>------->-------}
>------->-------case 2:
>------->------->-------x
>------->------->-------y
>------->------->-------...
>-------}

>-------switch(x) {
>-------case 1:
>------->-------{
>------->------->-------int a;
>------->------->-------qwe
>------->-------}
>-------case 2:
>------->-------x
>------->-------y
>------->-------...
>-------}

[alobalista]

Varianta cislo 1.

[pavlix]

Určitě druhá možnost, protože je konzistentní s tvým stylem. Chovej se k tomu, jako kdybys vytvářel blok uvnitř bloku a žádné case tam nebyly.

[Bedňa]

+1

[Miloslav Ponkrác]

Ani jedna možnost.

[xkucf03]

Líbí se mi první. U druhého nechápu, proč dáváš { } na nové řádky, když to jinak neděláš – IMHO zbytečnost. A naopak neodsazení case 1: a case 2: mi tam chybí. A odsazovat o 8 mi přijde moc – zkus nastavit šířku tabulátoru na 4 a nebude to tak „hluboké“.

[:::]

jsem zvykly na 8. Hlavne pri delsi praci se me to lip cte.

A obecne obvykle neodsazuju labely. Myslim ze tim ze se neodsadi dosahnu toho ze vycnivaji aniz bych pridal dalsi level zanoreni.

Zrovna tak jako u switche je neodsazuju ani u trid:

class xyz {
public:
>-------...
};

nebo goto:

int process() {
>-------...
error:
>-------...
}

Pokud jde o { na vlastnim radku, tak premyslel jsem i nad timhle:

>-------switch(x) {
>-------case 1: {
>------->------->-------int a;
>------->------->-------qwe
>------->-------}

to je pokud jde o { konzistentejsi, ale zase radek s } neni odsazeny stejne jako radek s { takze je to taky mirne nekonzistentni.

Taky jsem premyslel nad timhle, ale to by nemuselo vypadat dobre pri hodne kratkym tabulatoru:

>-------switch(x) {
>-------case 1: {
>--------------int a;
>--------------qwe
>-------  }

Zatim nejvic inklinuju k puvodni moznosti c 2. Musim se uz konecne rozhodnout a delat tohle konzistentne. Momentalne to mam pokazdy jinak jak se furt nemuzu rozhodnout Ale ne ze by tech switchu psal nejak moc...

[pavlix]

Líbí se mi první. U druhého nechápu, proč dáváš { } na nové řádky, když to jinak neděláš – IMHO zbytečnost.

Podle mě } na nový řádek dává za všech okolností a { spojuje pouze s řídící konstrukcí, na kterou se vážou (i z hlediska jazyka).

[Franta]

Tohle:

>-------switch(x) {

a tohle:

>-------case 1:
>------->-------{

mi nepřijde konsistentní.

[:::]

to je pravda, ale kdybych chtel byt maximalne konzistentni tak bych to musel psat takhle:

>-------switch(x) {
>-------case 1: {
>------->-------x...
>-------}
>-------}

tzn. prvni } by bylo odsazene stejne jako case. Proto me prijde lepsi byt trochu nekonzistentni a { dat na vlastni radek.

[pavlix]

To není vůbec konzistentní, natož maximálně.

[pavlix]

Chybně očekáváš, že se labely a řídící příkazy budou zapisovat stejně. Děláš to tak i mimo switch? Ta složená závorka je na samostatném řádku, protože je samostatná a z hlediska jazyka se neváže na žádný řídící příkaz a už vůbec ne na ten case.

Jasně, můžeš předstírat, že ano, po vzoru „pascalista píše v každém jazyce pascal“, ale pak jdeš zcela proti významu těch céčkovských konstrukcí.

[Franta]

Chybně očekáváš, že se labely a řídící příkazy budou zapisovat stejně.

Nemyslím, že je to chybný předpoklad, spíš logický.

Ano, v kódu si můžu udělat blok { } jen tak, třeba abych omezil rozsah proměnných nebo si nějak „označil“ nějaké místo* a pak tu { nepřidávám na konec předešlého řádku, protože tam žádný takový není a i kdyby byl, nedávalo by to smysl. Ale když je to uvnitř switche, smysl to dává – logický význam a to, co tím kódem chce člověk říct, je podobné jako u IFu, proto by se to mělo i stejně odsazovat.

Příklad:

if (a == 1) {
	…
}

obdobně:

switch(a) {
case 1: {
	…
}

*) moc se to nepoužívá a lepší bude ten blok vyčlenit do samostatné metody/funkce/procedury

[pavlix]

Nemyslím, že je to chybný předpoklad, spíš logický.

Typicky se labely zapisují takto:

... hlavička funkce ...
{
    ...
    goto konec;
    ...
konec:
    ...
}

A bloky vložené do jiných bloků tuším typicky takto:

{
    ...
    {
        ...
    }
    ...
}

Ale samozřejmě máš možnost to psát zcela libovolně narozdíl od Python apod.

[Franta]

Neřešíme, co je typické (např. pro mne je to { na stejném řádku jako if, else atd.), ale co je konsistentní se zbytkem toho stylu.

[pavlix]

Ty řešíš, co je konzistentní vůči tvému (špatnému) vnímání konstrukce v jazyce C. Já řeším, co je konzistentní vůči skutečným prvkům jazyka C. Tvé vnímání konstrukce označuju za špatné z toho důvodu, že nefunguje tak, jak naznačuješ, tedy case nefunguje jako if, ale zcela odlišně.

[Ondrej 'SanTiago' Zajicek]

Presne tak. V syntaktickem strome je if 'nad' prikazem/blokem, zatimco case je 'vedle' prikazu/bloku.

Dobre to je videt treba v pripade, kdy mezi case a blokem bude jeste nekolik prikazu:

switch(a) {
case 1:
    x++;
    y++;
    {
        int i;
        ...
    }
    z++;
    ...
}

Kdyz z takoveho kodu ty prvni dva prikazy eliminuju, je konzistentni zachovat stejne odsazeni bloku:

switch(a) {
case 1:
    {
        int i;
        ...
    }
    z++;
    ...
}

[Franta]

Viz #70: „logický význam a to, co tím kódem chce člověk říct, je podobné jako u IFu“.

(tím nepopírám, že teoreticky můžu nad ten blok {} dát další příkazy)

[pavlix]

Což jen potvrzuje, to, co jsem říkal. Ty vtiskáváš do odsazení své nepřesné vnímání fukce prvků jazyka. Já ti to nijak nevyčítám, to samé jsem dělal, když jsem byl nucen psát v Pascalu. Nicméně jako céčkař se snažím v céčku spíše držet skutečného významu jazykových prvků a ne nějaké zjednodušující interpretace.

[Franta]

Zatím jsem to nikdy nepotřeboval, ale napsal bych to takhle:

int a = 0;

switch (a) {
	case 0: {
		System.out.println("0");
	}
	break;
	case 1: {
		System.out.println("1");
	}
	break;
	default: {
		System.err.println("chyba");
	}
}

Dokonce jsem i zjistil, že tohle je výchozí (automatické) formátování v Netbeans

Případně bych dal ještě:

} break;

Asi nemá cenu zbytečně sklouzávat k osobním útokům…

Ty vtiskáváš do odsazení své nepřesné vnímání fukce prvků jazyka.

Proč by to tak mělo být? Konvence pro psaní kódu jsou z významné části věcí estetiky a osobního vkusu (proto se o nich také vedou nekonečné flamewary). Kdybych chtěl být ošklivý, tak řeknu, že ty zase podléháš iluzi, že odsazování by mělo být odvozeno čistě z technické specifikace jazyka bez ohledu na lidi, kteří ten kód píší a čtou.

[pavlix]

Zatím jsem to nikdy nepotřeboval, ale napsal bych to takhle:

Já ne, už jen proto, že nemám ve zvyku přidávat hromadu složených závorek jen tak pro okrasu.

Asi nemá cenu zbytečně sklouzávat k osobním útokům…

Nevím, jak jsi na to přišel, ale doufám, že se toho budeš držet :).

Proč by to tak mělo být?

Těkžo se mi vysvětluje věc, která mi připadá tak jednoduchá a samozřejmá. Měl jsem za to, že se shodujem v tom, že ti nevyhovuje sémantika céčkovského switche a omezuješ ji na určitou podmnožinu (zjednodušuješ) a takto zjednodušeně ji vnímáš. A toto vnímání vtiskáváš i do formátování.

Když mi pomůžeš specifikovat, co je na tom nejasné, tak zkusím nějak reagovat.

Kdybych chtěl být ošklivý, tak řeknu, že ty zase podléháš iluzi

Ano, to už zní ošklivě. Máš důvod být ošklivý?

[alobalista]

BTW nevi nekdo proc jsou zdrojaky standardni knihovny Javy tak silene indentovane? Skoro vsude se mixujou TABy s mezerama. A skoro mi prislo, jakoby to byla vlastnost nejakeho jejich editoru v kterem to psali, nez vysledek prace vice lidi s jinym stylem.

[Dreit]

Netbeans? Bouchnu tabulátor, udělá se tabulátor. Dám backspace a maže to po jednom znaku místo celýho tabulátoru

[xkucf03]

Nemáš tam nastavenou emulaci tabulátorů pomocí mezer? To by totiž odpovídalo.

[Dreit]

Pokusim se to najít, myslel jsem že je to hardcoded feature

Rozhodně někdo smazal konfiguraci, takže to má celej ČVUT zase v defaultu

[xkucf03]

Příloha:

• netbeans.png (74166 bytů)

Viz příloha: Expand Tabs to Spaces. Mám za to, že ve výchozím nastavení je to odškrtnuté.

[Miloslav Ponkrác]

Protože to byl běžný styl před 20 lety.

Možná to nevíte, ale na mnoha počítačích byly hard disky, které měly velikost několika megabajtů.

Ušetřit poměrně značnou velikost tím, že nahradíte sérii mezer tabulátory tam, kde vizuálně bude stejný výsledek je velká úspora. Řada editorů to dělala automaticky nebo to umožňovala navolit.

Já jsem to dělal v minulosti taky tak.

Při ukládání na 360 KB disketu bylo každé šetření místem žádoucí.

Moje první programy v C jsem psal (pokud vynechám sálové stroje a různé bezdiskové minimašiny předtím) na PP06, který neměl hardisk, ale pouze dvě 360 KB disketové šachty. První disketa = editor + kompilátor C + knihovny + linker. Druhá disketa = zbývající knihovny co se nevěšly na první + moje zdrojáky + místo na ukládání meziproduktů kompilace + místo na výslednou binárku.

Věřte mi, že komprese pomocí tabelátorů + mezer byla docela vítaná.

[alobalista]

Nechapu, prece kdyz budu chtit usetrit, tak budu pouzivat jen a pouze TABy. Kombinovanim s mezerama pocet bajtu bude vetsi ne?

[pavlix]

Tam jde o to, že to navrhoval někdo naprosto bez představivosti nebo hodně unavený v době, kdy to vymýšlel. Vychází to jako logický důsledek tří axiomů.

1) Odsazování se dělá o čtyři mezery

2) Taby na začátku řádku mají vždy 8 mezer

3) Potřebujeme co nejméně znaků

Z toho ti totiž vyjde, že odsazení je půl tabu a tudíž je nutné ho tvořit mezerami (1,2), zatímco dvě odsazení už jsou celý tab a je potřeba je realizovat tabem (3). Pochopitelně tři odsazení vyžadují jeden tab a čtyři mezery.

To je tak, když tyhle věci vymýšlí lidé, kteří měří na palce a stopy, a pak to má používat někdo, kdo je zvyklí na konzistentnější systémy.

[alobalista]

No to teda koukam. Diky za vysvetleni .

[pavlix]

:D

[paranoik]

Tohle mě taky štve. Mě to připadá jakoby generátor tříd používal 4 mezery a většina vývojářů tabulátor. Když si nastavíš tabulátor na velikost 8 mezer tak je většina věcí formátovaná správně i když nelogicky (např. odsazení kódu metody je 1 tabulátor, její deklarace 4 mezery).

[Miloslav Ponkrác]

Vždy jsem používal pouze mezery a dodnes nevidím jedinou výhodu tabelátorů.

Řídím se heslem, že tabelátory nemají ve zdrojových kódech co dělat. Pokud se objeví v cizím kódu, zkonvertuji je na mezery.

Tabelátory dokonce ani nenesou sémantickou hodnotu, protože v běžných programovacích jazycích jsou pravidla odsazování tak jednoduchá, že přeformátovat zdroják tak jak mi to vyhovuje zvládne velmi jednoduchý prográmek automaticky i bez toho, aby se programátor s nějakými tabelátory patlal.

Lidi stejně tabelátory sázejí chybně už jen z titulu, že je nevidí.

Jinak řečeno, tabelátory v běžných zdrojácích považuji za ptákovinu, protože nemají kromě žádnou funkci. To co se uvádí jako jejich výhoda se snadno zajistí i bez nich, jako je přeformátování na jiné odsazení, apod.

Když se dívám do cizích zdrojáků, velikost odsazení je poslední co mi vadí. Daleko více mi vadí různé formátování složených závorek, nebo jiný počítků/konců bloku. Způsob formátování cyklů, hlaviček funkcí, atd. – a v tom tabelátory nepomůžou.

Tam, kde tabelátory mají informaci pak je nebezpečné odsazovat vždy tabelátory, např. v makefile, v datových souborech s políčky oddělenými tabelátory, apod. Zde mají tabelátory skutečnou sémantickou hodnotu, protože na rozdíl od zdrojových kódů přidávají informaci, kterou nelze vydedukovat.

Jinak řečeno, vidím u odsazování tabelátory pouze nevýhody. Přeformátovat odsazení cizího zdrojáku jde i při odsazování mezerami. Navíc dochází k interferenci v textových souborech, kde tabelátory mají nějakou užitečnou funkci – zejména datové souory jsou v posledních letech dodávány výhradně s tabelátorem jako oddělovačem údajů.

[xkucf03]

Přeformátovat odsazení cizího zdrojáku jde i při odsazování mezerami.

Jenže to znamená zásah do souboru, změnu prakticky všech řádků…˙Šířka tabulátorů je oproti tomu čistě věc zobrazení a nemusím do souboru nijak zasahovat. Někdo odsazuje o 2, normální lidi o 4, extrémista i o 8… každému vyhovuje něco jiného (liší se i podle jazyka). S tabulátory si to každý nastaví podle svého a přitom můžou všichni editovat ten samý soubor.

Když na to špatně uvidím, zvýším si šířku tabulátoru, udělám potřebné změny a odešlu je (měním jen některé řádky). Ale když dostanu po někom zdroják s odsazením o 2 mezery a bude se mi to špatně číst (záleží na jazyku, někde je to OK), tak to budu muset nějak přetrpět nebo to přeformátovat, ale pak budou v nové verzi změněné všechny řádky, což dělá jednak bordel ve verzovacím systému a jednak tím budu otravovat ty, kterým odsazení o 2 mezery vyhovovalo. Totéž platí pro 8 nebo 3 (i takoví exoti se najdou).

[:::]

presne to me napadlo. To musi mit kolegove radost kdyz porovnavaji verze a nekdo si jen tak pro radost preformatoval cely soubor

[Miloslav Ponkrác]

Při práci v týmu dodržuji projektem zvolený coe stylu bez ohledu na to, co si o něm myslím.

Kromě toho porovnávací nástroje, které nejsou s to se vyrovnat s náhradou tabelátorů za mezery neznám, okamžitě jdou do /dev/null, kromě spláchnutí do WC se na nic jiného nehodí.

[Sten]

A proto je vhodnější, když při sepisování toho coding style někdo myslel, než že jen vzal to, co se líbí jemu.

Můžete nám prozradit, který používáte verzovací systém, jenž ignoruje změny tabulátorů na mezery?

[Ash]

Aha, takže zase takové ty polopravdy a poloinformace.

Pokud se objeví v cizím kódu, zkonvertuji je na mezery... ale jen pokud tomu nebrání coding style.

Přeformátovat zdroják tak jak mi to vyhovuje zvládne velmi jednoduchý prográmek automaticky... ale lze to jen když to neodporuje coding style týmu, jinak mám smůlu a musím denně trpět u 8 mezerových odsazení. Ale přesto trvám na tom, že tabelátory nemají žádnou výhodu, i když by mě toho utrpení mohly ušetřit, ale ne, já si to nepřiznám a nepřiznám...

[Miloslav Ponkrác]

Mám pocit, že zastánci tabulátorů dělají, že nerozumí co píši.

Odsazení, podle toho, jestli mi vyhovuje odsazení o 2,4, 8, či jiný počet udělám bez ohledu na to, zda je odsazováno mezerami nebo tabulátory. Programovací jazyky jsou obvykle tak syntakticky jednoduché, že to udělá automat za programátora. Pokud není jiný důvod, proč odsazovat tabulátory, pak nemá používání tabulátorů pražádný význam a je k ničemu. Kromě toho, že se s tím programátor patlá a musí řešit něco, co řešit nemusí – tedy rozlišování tabelátorů a mezer. Tedy programátor odsazující tabelátory pracuje stylem „nevadí, že se víc nadřu bez jakéhokoli smyslu“.

Jak si pak nastavíte to, že někdo používá odlišný code style? Někdo dává počíteční složenou závorku na stejný řádek jako příkaz podmínky a cyklu, jiný pod něho.

Nebo ještě daleko více na čitelnost zdrojáků má vliv způsob vytváření názvů identifikátorů – jmen proměnných, podprogramů, modulů, atd.

Při luštění cizích zdrojáků jste nuceni překousnout tolika věcí, že odsazování je to nejmenší.

[mirec]

Příloha:

• editor.png (18810 bytů)

Odsazení, podle toho, jestli mi vyhovuje odsazení o 2,4, 8, či jiný počet udělám bez ohledu na to, zda je odsazováno mezerami nebo tabulátory.

To bude mať autor pôvodného kódu radosť, že mu niekto rozrýpal odsadzovanie aké jemu vyhovuje. Nehovoriac o následnom merge cez VCS, ktoré kvôli odsadeniu nebude fungovať, takže bude musieť mergovať ručne.

Tedy programátor odsazující tabelátory pracuje stylem „nevadí, že se víc nadřu bez jakéhokoli smyslu“.

Alebo nevadí mi, že pri zmenšení odsadenia musím 4x (alebo 2x, 3x, 8x, 6x ...) ťuknúť do backspace namiesto 1, že. Inak o zobrazovanie tabulátorov a medzier a ich správne mixovanie (taby na indent, medzery na zarovannie) by sa mal starať editor pokiaľ sa nemýlim (príloha).

Při luštění cizích zdrojáků jste nuceni překousnout tolika věcí, že odsazování je to nejmenší

Škoda, že neviem práve vyhrabať štúdiu, ktorá hovorí presný opak.

[Bystroushaak]

Alebo nevadí mi, že pri zmenšení odsadenia musím 4x (alebo 2x, 3x, 8x, 6x ...) ťuknúť do backspace namiesto 1, že.

Většina editorů co jsem kdy v životě používal tohle implementuje pomocí shift+tab.

[pavlix]

Editor, který používám, zvládá i ten backpace.

[mirec]

Ako kde, väčšinou sa u medzier stretávam s takým bordelom, že niekde je 1 medzera, 2, medzery, 3 medzery, 4 medzery ... takže nájdenie správneho odsadenia editor nedokáže ak nie je nastavený na pevný počet (ani to ešte nemusí byť správne).

[Bystroushaak]

Neříkal jsem nic o autodetekci, musíš nastavit ručně v menu šířku odsazení. Výhoda je, že pak nemusíš mačkat několikrát backspace, navíc se to používá i na posouvání celých bloků (pythonisti určitě znají).

[pavlix]

Nejvtipnější jsou gnomácké zvyklosti psaní kódu, které kombinaci tabů a mezer vyžadují a jsem přesvědčen, že jestli existuje nějaký editor, který ten jejich styl umí správně, tak je pouze jeden na světě. Ale spíš si myslím, že to žádný editor nedává a programátor si musí hrát s mezerníkem na datla.

[petr_p]

Já mám dojem, že je to výchozí nastavení Emacsu.

[pavlix]

Jo :).

jestli existuje nějaký editor, který ten jejich styl umí správně, tak je pouze jeden na světě.

[pavlix]

Škoda, že neviem práve vyhrabať štúdiu, ktorá hovorí presný opak.

Tak si jí vycucej z prstu stejně jako kdokoli, kdo mohl takovou studii vyplodit (nejspíš, pokud to myslel vážně, tak se v ní píše úplně něco jiného, než n mezer odsazení je čitelných, zatímco m ne).

[mirec]

Díky za označenie exot. Ja považujem 2 medzery za málo čitateľné a 4 zase pri šírke zdrojáku okolo 580px príliš veľa. Preto preferujem taby, kde mám pekne nastavenú šírku na 3 znaky a nikoho neotravujem pomerne neštandardnými 3 medzerami.

[xkucf03]

nemyslel jsem to nijak zle. Dvě jsou relativně málo, ale někdy se to celkem dá a i jsem si na to zvykl (Pascal). Liché číslo mi přijde takové divné a 4 jako akorát.

[Let_Me_Be]

Jeste jsem nenasel program, ktery by umel korektne preformatovat C a C++ kod. Vsechny code-beautifiers na netrivialnim kodu selhavaji.

[pavlix]

Výhoda tabulátora je práve v tom, že na odsadzovanie textu bol navrhnutý a vie zarovnať stĺpce.

Vážně umí zarovnat sloupce? V některém z běžně používaných editorů? A vážně byl navržen na odsazování kódu? Tomu moc nevěřím.

[Bedňa]

Tak som bol naučený, že je to sématickou značkou pre odsadenie textu a zarovnanie do stĺpcov, niečo podobné tvrdí aj Wikipédia. Teda aj editory s ktorými pracujem sa stavajú k vyjadreniu tabulátora rovnako, akurát z rozličným odsadením.

[Bedňa]

Som neodpovedal na editor, tak napr. Netbeans a Eclipse. Je pravda že som si nastavenia robil sám, tak možno by default to tak nebolo, kto si to už pamätať

[Bedňa]

Aha som si tvoj koment prečítal ešte raz, nie na odsadenie kódu, ale textu.

[Miloslav Ponkrác]

Já bych to vylepšil. Já bych od levého okraje ve zdrojáku zarovnával tabulátorem (znakem U+9), mezi jednotlivými funkcemi či metodami bych vertikálně odděloval vertikálním tabulátorem (U+B). Čím by si každý mohl v editoru levé odsazení i odsazení mezi metodami navrhnout dle svého.

Kromě toho bych nemazal ve zdrojáku při opravách opravdově, ale následoval bych znaky Backspace (U+8), takže bych ve skutečnosti nikdy nic nemazal. Pouze editor by to posuny kurzory přepsal, ale v souboru by to zůstalo. Mohl bych si tak v rámci editoru nahradit i VCS (správce verzí).

Konec srandy.

Zkrátka pořád nevidím jediný benefit používání tabulátorů. Kromě iracionálního zvyku bez rozumného argumentu.

[xkucf03]

A co mazání resp. snižování úrovně odsazení? Používáš na to backspace nebo nějakou zvláštní klávesovou zkratku a funkci prohlížeče? Já používám tabulátory tzn. tabulátorem zvyšuji odsazení a backspacem snižuji – nemusím ho mačkat 2×/4×/8×. (případně používám Alt+šipky pro zvýšení/snížení odsazení, což funguje i na více řádků a člověk nemusí být na jeho začátku).

[Miloslav Ponkrác]

Normálně, já taky nemusím mačkat backspace 2×/4×/8×, a to používám mezery. Možná bych Ti měl sdělit, že když tu klávesu držíš, ona opakuje automaticky.

Kromě toho rozumný editor má autoindent, který leccos zařídí sám jak při vytváření osazení, tak při jeho rušení.

[Ash]

Benefit je právě v tom, že si to horizontální odsazení může každý nastavit. Alternativa v podobě "VCS pro odsazení" neexistuje, je to jediná možnost jak to dělat.

Vertikální odsazení je zajímavá myšlenka, ale asi to nikdo nepotřebuje.

Nemazání za účelem verzování? Na to už byl přece vynalezen ten VCS, tak proč funkci duplikovat či integrovat v editoru, když již existuje? Opakuji že pro odsazení žádné "VCS" neexistuje, takže se to řeší tabelátory. Benefit je zřejmý - možnost si to nastavit.