space vs tab

Alapvetoen nem szamit, hogy tab vagy space. A fontos az, hogy mindenki ugyanazt hasznalja, kulonben olvashatatlan lesz a kod.

En alapvetoen space parti vagyok es pont azert mert tisztan tabbal nem lehet mindent igazitani es igy a tab valamilyen szinten mindig kevert lesz. Ha ehhez hozzaveszed, hogy sok okos editor automatikusan konvertal tobb egymas mellett levo space-t, akkor azonnal latod, hogy a tab "veszelyes". A space viszont mindenhol egyforma.

Nincs esetleg olyan editor, ami megnyitás után a sor eleji n darab space-t tab-ként jeleníti meg a szerkesztés idejére, majd mentéskor a tab-okat n darab space-ként írja fájlba?

Én szigorú tab párti vagyok.
A vi editorban tabstop=4, a commenten kívül csak az utasítás és paraméterek között lehet space. Így az igazítást mindig tab végzi. A sorok végén nem lehet sem tab, sem space. Ezeket a szabályokat betartva akár hiba is kiszűrhető. Pl. laza egérmozdulat következménye. :)
A 4 hosszú tab meg először a hosszú sorok miatt alakult ki.
A tab indentálás C esetén fontos, mert a pascal előélet miatt nem a blokk kezdetéhez igazodik a záró kapocs, hanem a nyitóval egy mélységben.
ASM forrásnál 13, 25 és 49 a megfelelő pozíció.
No, ennyit a magánéletről. :)

En tab parti vagyok, de kenyszerittetek a kigyo imadok. Sot a szerkesztom is 4 spacet ir egy tab lenyomasara,
holott mindenki tudja, hogy 8 lene ;-)

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Makefile az tab parti ;)
http://stackoverflow.com/questions/2131213/can-you-make-valid-makefiles…

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

(Én csak azoknak a lassú kínhalálát szeretném megélni, akik azt hiszik, hogy a TAB egy szabadon állítható valami. Nem, annak kb 50-60 évvel ezelőtt definiálták a jelentését: ugrás a következő 8k+1 pozícióra.)

Szerk: tegyük hozzá, hogy a fenti a 'formátumozatlan üzemmód'-ra vonatkozik, amilyen pl. egy textfile.
Formátumozott üzemmódban (amilyen például egy HTML-form) a TAB a következő mezőre/zónára/definiált TAB-pozícióra ugrik.

En tabot nyomok, de a szovegszerkesztom/IDE mar a megfelelo szamu szokozt rogzit a forrasban. Egyebkent meg EditorConfig es mindenki boldog.

Tab:
- Már általános iskolában megtanultuk, hogy szóközzel nem formázunk (igaz, szövegszerkesztés esetében)
- Egy tab egy karakter, sok space hány karakter? :)
- A tab olyan széles lehet, ahogy szeretnéd, vagy más szeretné

Kell több érv? :)

Alapvetoen smart-tab parti vagyok, de a legritkabb esetben kell ezzel foglalkoznom. Az editorom a legtobb esetben kitalalja, hogy az adott kodban epp mi a szokas, es ahhoz alkalmazkodik. Indentalaskor en tabot nyomok, az Emacs pedig azt ir be, amit jonak gondol.

--
|8]

"Pontosabban smart-tab párti (remélem ez a megfelelő terminológia; arról a formázási megoldásról beszélek, ahol a tab szigorúan a kód indentálására vonatkozik, azonos indentálási szinten belül az egymás alá igazítást szóközzel végzem.)"

"(ez utóbbi kérdésre egyébként azt a választ szokták adni, hogy elcsúszhat a kód ott, ahol egymás alá igazítás lényeges. Na de erre lenne jó a smart tab megoldás, nem?)"

Azt hiszem nem igazán értem, hogy mit nevezel pontosan smart tab-nak. A kód akkor csúszhat el, ha az indentálás nem pontosan az egyikkel van mindenhol megoldva, ha keverve van, akkor csúszhat el. Amennyit értek a smart tab leírásodból, hogy nálad keverve van, ne ez az amikor nem jó!

"tab szigorúan a kód indentálására vonatkozik, azonos indentálási szinten belül az egymás alá igazítást szóközzel végzem."

Igazából azt nem értem, hogy azonos indentálási szinten belül mit is kellene igazítani! Azonos indentálási szintnél minden ugyanott kezdődik, tehát nem kell semmit sem eltolni (space-ekkel).

Szerk.: Közben rájöttem, hogy a szóközzel egymás alá igazításon a soron belüli igazítást érted, pl. a változónevek, értékek, ... egymás alá igazítását. (No ezt se látom egy hasznos dolognak)

Régebben TAB párti voltam, mostmár inkább space-t használok.
De úgy hogy a vim-ben továbbra is tab-ot nyomok, ami helyett ő beállítástól függően 2-4 space-t rak...

Az indok: a tab mindenhol máshogy néz(het) ki, míg a space egészen biztosan mindenhol ugyan úgy.

--
zrubi.hu

vim
:set tabstop=2 shiftwidth=2 softtabstop=2 expandtab
Nálunk ez coding rule.

A témához kapcsolódva ez egy elég jól összeszedett leírásnak tűnik:
http://vim.wikia.com/wiki/Indent_with_tabs,_align_with_spaces

Nalunk is mindenhol szokoz van, CodeSnifferrel ellenorizve minden commit utan. Ha mas a szabvany az adott projekthez, akkor mi is azzal dolgozunk.

Editorconfig nagyon hasznos tud lenni a szabvany definialasakor, tehat minden IDE (vagy text editor) egyszerre igazodik:
http://editorconfig.org/

Nincs annal rondabb, mint amikor tab es space keveredik. A smart tab az mas, bar egyel tobb dolog, amire figyelni kell.

Két idióta nyelv esetén lényeges, az egyik a whitespace, a másik a Python :-P

Ha már flame wart indítasz:

"arról a formázási megoldásról beszélek, ahol a tab szigorúan a kód indentálására vonatkozik, azonos indentálási szinten belül az egymás alá igazítást szóközzel végzem"

Na én meg sehogy, és mindenkit lebeszélek róla. Pláne erről a stílusról:

foo       = f1;
foobar    = f2;
foobarbaz = f3;

x = foo      (valami);
y = foobar   (valami);
z = foobarbaz(valami);

Több okom is van rá:

• Csapnivaló editor támogatás, előbb-utóbb elkezdesz kézzel indentálni, emiatt nem használhatod az automatikus formázást, vagyis ha véletlenül nem veszel észre egy formázási hibát, az meg is marad.
• Ha hozzáírsz vagy törölsz egy sort, borul az egész blokk formázása, tehát indentálhatod újra az egészet. Ez ronda és hosszú diffeket eredményez.
• Bár elsőre jó ötletnek tűnik, hogy milyen jól olvasható lesz majd a vertikálisan igazított kód, valójában az egész kód jobbra csúszik, hatalmas üres helyeket hagyva a kódsorok közepén, emiatt az eredmény nehezen lesz olvasható.
• Ha már a formázást kell segítségül hívni, hogy olvasható legyen a kód, az egy igen erős code smell. Ennél már csak a goto jellegű utasítások (return, break, continue), a commentek és külön kategóriában a TODO és FIXME commentek rosszabbak.

Egyébként én is tab párti vagyok, de egy jó editorban igazából mindegy. Egy érvem van viszont ellene: nem minden toolban lehet tab size-t állítani, és valamiért ezekben a toolokban tipikus a 8 karakteres tab, aminél tényleg jobb a 2/4 karakteres space indent.

Szóköz.

A TAB létjogosultsága szövegfájlban erősen kérdőjeles. Ha újra lehetne kezdeni a számítástechnikát, felszólalnék a mellőzése érdekében. Billentyűként a billentyűzeten, vagy ASCII 9-es kódként oké, mint ahogy például a Backspace is, de szövegfájlban (a Backspace-hez hasonlóan) nincs létjogosultsága.

A TAB nem nyomtatható karakter, hanem vezérlő utasítás, a Backspace-hez, Newline-hoz és különféle escape szekvenciákhoz hasonlóan. Termimálba kiírva például nem törli ki (nem írja felül szóközökkel) az átugort betűket, hanem azokat békén hagyva egyszerűen előre ugrik valamennyit a kurzor. A Newline sajnos megkerülhetetlen szövegfájlokban, mivel 2 dimenziós betűtömböt kell 1 dimenzióssá leképezni, így szükség van elválasztó karakterre. A TAB-ra ez nem teljesül, anélkül boldogan lehet élni, és aki megszabadul tőle, az a legegyszerűbb huszárvásággal szabadult meg egy tök fölösleges és ilyesmi vitákra okot adó dologtól.

Egy szövegfájl, sőt, egy forráskód – ezt az egyet leszámítva – a kinézetet specifikálja. Betűk, újsor, melyeknek mind pontos kinézetük van. A jelentést később az IDE és a fordítóprogram adja hozzá. A szövegfájl szintjén nem jön be a szemantika. Nincs olyan karakter, hogy „metódus vége” vagy „osztály vége”, melyet bekonfigurálhatnék az IDE-ben, hogy hány sor kihagyásra szeretnék. (Régesrégen páran a form feed-et használták erre, azóta remélem ez a szokás már rég kihalt.) Nincs olyan karakter, hogy „kódblokk nyit”, amely az IDE preferenciái szerint tenné a nyitó kapcsos zárójelet a sor végére, vagy a következő sorba. És így tovább. A szövegfájl tartalma pusztán kinézet, semmi több.

Kivéve persze a TAB-ot, mert ez az egyetlen karakter szemantikát akar hordozni már a fájl szintjén is. Miért? Nem látok semmi okot, ami létjogosultságot adna neki. Ha nem létezne, senkinek nem jutna eszébe kitalálni.

Ahogy a kapcsos zárójel helyzetével, az operátorok körüli szóközökkel, és kismillió hasonló dologgal kapcsolatban a használt kódolási stílus adja meg a kinézetet, melyet a szövegfájlban meg kell valósítani, nem látom, hogy az indentálás miért érdemelné meg, hogy egyetlen kivételként „meta” szintre emeljük és úgy kódoljunk, hogy a forrásfájl egyszerre többféleképp is kinézhessen szépen olvashatóan.

Aki valaha kilépett már az IDE világából, és cat-olt kódot terminálra, futtatott diff-et, inline-olt e-mailbe, copy-paste-elt stb., tuti sokat szívott a TAB-bal, míg a szóközzel aligha.

> ahol a tab szigorúan a kód indentálására vonatkozik, azonos indentálási szinten belül az egymás alá igazítást szóközzel végzem

Régen én is így csináltam. Megbukik, ha tartanod kell magad valami jobb margóhoz (például 80 oszlopot követel a projekt kódolási stílusa). Megbukik, ha szeretnél jobb oldalt egy szépen kinéző, több (eltérően indentált) soron keresztül átívelő kommentet. De leginkább gyakorlatilag észszerűtlen a karbantartása, leellenőrizhetetlen hogy jól csináltad-e, avagy rakat időt elcseszel a leellenőrzésére, illetve az ezzel kapcsolatos reflexszé váló szokás rabolja hosszú távon az idődet a tényleges kódolástól.

> véletlenül két szint közé kerültem, és elcsúszott a kód [...] elcsúszhat a kód ott, ahol egymás alá igazítás lényeges

Itt kell az IDE-nek segítenie. Ha szóközökkel elcsúszhat, akkor TAB-bal is – mikor szúrod ki, ha a TAB után ott van még egy szókoz?

> problémás volt idegen, máshogy szintezett kódot használni

Fogadjunk, hogy nem jobban, mint másmilyen kapcsoszárójelezésű, operátorok körüli szóközözésű, vagy bármi egyéb szempontból másmilyen stílusú kódot használni.

Nem értem, miért kéne „meta” szinten, vagyis többféle beállítással jól kinéző módon kódolni, ahelyett hogy egyféleképpen írnám meg. Fölösleges pazarlása a szoftverfejlesztői erőforrásoknak.

Ha már érdekel annyira a téma, hogy megkérdezted a HUP-on, határozottan a TAB-ok teljes elhagyását javaslom: Szerintem ez az egyetlen út, amellyel megnyugtatóan lehet egyszer s mindenkorra a legtisztább és leghatékonyabb módon lerendezni ezt a dilemmát.

Két eset van:

Az egyikben a nyelvben számít, hogy tab vagy szóköz van bizonyos helyeken (pl. Python) --> itt egyértelmű, hogy mit és hogy kell használni, hiszen az eredmény eltér attól függően, hogy tab vagy szóköz.

A másikban a nyelvben nem számít, hogy tab vagy szóköz vagy mindkettő van, a kód olvashatósága miatt használjuk bármelyiket is --> itt sosem értettem, hogy miért kell hülye szövegfájl-formázásokkal játszani (akár tab-szóköz, akár sorhossz, akár hasonlók kapcsán), helyette ezt javaslom:

- a fájlban írjuk le, hogy "if(a>1){print(b);};"
- az egyik fejlesztőnek jelenítsük meg így:

if ( a > 1 ) {
print(b);
};

- a másik fejlesztőnek meg így:

if (a>1)
{
print(b);
}
;

Vagy ahogy akarják. Mindaddig, amíg ezek eltérő eredményre nem vezetnek, csak akarat kérdése, hogy hol így, hol úgy jelenjen meg a kód. Persze vannak idegesítő mellékhatások, pl. az, hogy a "hányadik sorban van a print(b)" kérdésre nincs egyértelmű válasz, dehát valamit valamiért :-)

Itt szépen össze van szedve, hogy:
- miért sokkal jobb a TAB
- miért ne használj soha TAB-ot

Nekem csak a tab indentalasra.
Azt is elmondom, hogy miert: az valtozik, hogy hogyan esik jol olvasni a kodot, van, hogy a negy space kellemes a szememnek, van, hogy a ketto, van, hogy a nyolc. Ha tabbal indentalok, akkor ezt barmikor meg tudom valtoztatni menetkozben.
Semmi ertelme nincs annak, hogy space-szel indentaljunk.

A világ legértelmetlenebb témája. Döntse el adott cég/projekt, aztán mindenki kövesse azt.

Nálunk pl. ez meg van mondva, oszt' kész:
https://google.github.io/styleguide/cppguide.html#Spaces_vs._Tabs
https://google.github.io/styleguide/javaguide.html#s4.2-block-indentati…

Személy szerint régen Visual Studióval nyomtuk a cégnél, ami default space-es beállítással települ. Én írtam egy style guide-ot, meg volt mondva, illetve group policy is volt rá, hogy ezt tabra cseréljük. Aztán olyan sűrűn találkoztunk nem tabos kóddal, meg folyton jött ki új Visual Studio, meg mittudomén (kb. 3 éve volt, jellemző, hogy annyira lényegtelen téma, hogy már nem is emlékszek rá), feladtam a küzdelmet, töröltem a group policyt, és inkább az lett a mondás, hogy egy az egyben default formázást használunk, és kész. Ahogy a világon senki más, én se tudtam egyértelműen eldönteni, melyik a jobb, de a space volt egyszerűbb és elterjedtebb, ennyi.

Most is inkább space felé hajlok, de az IDE-re bízom az automatikus indentálást (asszem tab billentyűt nyomok túlnyomó többségben, az meg csinál vele, amit akar). Ha valaki elémrak egy máshogy konfigurált IDE-t, ami automatikusan jól tabozik, és nekem nem kell vele foglalkozni, eszembe se jutna küzdeni vele. Lényeg, hogy részemről minimális erőfeszítés legyen a stílust követni. Ennek a vitának se látom értelmét, de azért csak hozzászóltam :).

--

https://www.emacswiki.org/pics/static/TabsSpacesBoth.png

--