Fórum Root.cz
Hlavní témata => Vývoj => Téma založeno: ts 06. 09. 2012, 16:29:09
-
Tabulátory nebo mezery ve zdrojovém kódu?
-
enter
-
Tabulátory nebo mezery ve zdrojovém kódu?
Jablkovy alebo orechovy kolac?
-
ODS nebo ČSSD?
-
Root nebo Blesk?
-
Stanovení šířky osazení (obvykle 4 znaky, případně 8 nebo 2) a rozhodnutí zda pro odsazování používat tabulátory nebo mezery je důležitou součástí konvencí pro psaní kódu každého týmu. Použití tabulátorů je vhodnější v tom, že v kódu je uložena sémantická informace: počet úrovní odsazení (=počet po sobě jdoucích tabulátorů) nikoli jen shluk mezer, který sám o sobě (bez znalosti dané konvence – šířky) o počtu úrovní nic nevypovídá. Na druhou stranu může použití tabulátorů přinášet problémy – při rozdílně nastavených editorech jednotlivých programátorů a nedodržování konvencí může kód u jednoho programátora vypadat správně odsazený, zatímco u jiného špatně.
http://cs.wikipedia.org/wiki/Styl_z%C3%A1pisu_programu
-
ach, vidim chlapci, ze netusite, o co v otazke ide...
ja osobne hlasujem za tab. ak si takto formatovany subor vymienaju medzi sebou rozne osobnosti, kde kazdy ma svoje id nastavene inak, ale vsetci spravne, je sanca, ze vzdy vsetci uvidia u seba subor formatovany podla vlastnych preferncii a ako je to im mile. pokial by si na odsadzovanie pouzival medzery, po tyzdni rotacie medzi editormi by si mal jeden dopraseny hnoj, ktory by sa len tazko dal citat.
ako pri vsetkom, aj tu je vynimka. python:) ale to take hrozne neni, kedze tam je to riesene striktne a zauzivane su 4 medzery. pri pythone je sanca, ze do znacnej miery vsetci budu odsadzovat rovnako. aj ked, mam pocit, ze predsa len funguje spravne aj tab:)
mam mnoho skusenosti s takymi subormi, ktore boli editovane viacerymi a kazdy mal svoje oblubene ide a kazdy ho mal nastavene inak:) jedine taby sa osvedcili...
-
ja som za tab ale ono to je asi jedno.. nie je problem prekonvertovat
-
Je to hlavne zalezitost osobni preference. Kdyz pecko zminil ten Python, je o tom napsano par radku v PEP [1][2]. Jinak osobne bych volil pro from scratch projekt (4) mezery. U existujiciho projektu se urcite drzet toho, co se v nem pouziva.
Co se tyce mixovani tabu a mezer... nemam s tim zkusenosti, ale i tak k tomu duveru nemam.
[1] http://python.org/dev/peps/pep-0008/#tabs-or-spaces (http://python.org/dev/peps/pep-0008/#tabs-or-spaces)
[2] http://python.org/dev/peps/pep-0007/#code-lay-out (http://python.org/dev/peps/pep-0007/#code-lay-out)
-
Taky pouzivam 4 mezery (C, PHP) a pro html jen dve. A hodne se divim ze z dob davnejsich pochazi standardy typu tab = 8 mezer a zaroven limit na 80 zn/radek :)
-
Když se používání tabů vyloženě vyžaduje, tak se přizpůsobím, ale jinak používám zásadně mezery.
-
U nás šéf rozhodl pro TAB. Pro editování C# kódu je to dobře, pro XAML na h*vno.
V jiném týmu to můžou být mezery, který jsou dobrý k něčemu jinému, ale u něčeho vás pořádně vyliskají. Člověk si prostě nevybere
-
ach, vidim chlapci, ze netusite, o co v otazke ide...
Samozřejmě o flame, tak pojďme do toho ;-)
Spousta doporučení (např. Java coding style guide) říká nepoužívat Tab, ale mezery. Důvod byl řečen výše - při použití jiného nastavení šířky tabulátoru, než jaké použil autor, se pak formátování řádek s různými úrovněmi odsazení rozpadá.
A pokud je někdo neschopný nastavit si IDE podle konvencí projektu... no tak mu prostě jeho výtvory revertněte a řekněte mu, ať si to nastaví!
-
... při použití jiného nastavení šířky tabulátoru, než jaké použil autor, se pak formátování řádek s různými úrovněmi odsazení rozpadá.
A pokud je někdo neschopný nastavit si IDE podle konvencí projektu... no tak mu prostě jeho výtvory revertněte a řekněte mu, ať si to nastaví!
prepac, ale ak mas niekde povedzme 2x \t na zaciatku riadku, mas tam 2x \t na zaciatku riadku a hotovo. tvoje nastavenie ide s tym nic nespravi. ak mas syndrom americana, potrebujes obrovske mnozstvo medzier, tak si nastavis svoje ide, aby 1 \t zobrazoval ako 12 medzier. to je cele. a kedze mas na zaciatku 2x \t, medzier vo svojom ide budes mat 24. ake rozpadanie? pokial tam kazdy editor zachova tie dva taby, dva taby tam stale ostanu a nic sa nerozbije. a pokial by vsetci koderi dodrziavali odsadzovanie tabom, neexistuje moznost, ako by mohlo dojst k rozbitiu kodu. kazdy vo svojom ide uvidi len to, co si vo svojom ide nastavi, ale nijako tym neovplyvni skutocny obsah suboru.
co plati pri nejakych specifickostiach ako pythom, ci xaml, ci neviem co este, to je o niecom inom. pisem prevazne o jazykoch, ktore nie su citlive na odsadzovanie a formatovanie je len vecou vseobecnej dohody. tam jednoznacne tab, pretoze je debilovzdorny.
a inak, verim, ze o falme tym tajtrlikom na zaciatku neslo, iba nepochopili otazku:)
-
pecko:
http://www.iovene.com/61/ (http://www.iovene.com/61/)
-
pecko:
http://www.iovene.com/61/ (http://www.iovene.com/61/)
presne tak som to myslel. sory, ak som sa nevyjadril dost jasne. mal som na mysli iba odsadzovanie, nie zarovnavanie. presne ako autor clanku pise, na odsadzovanie je najlepsi tab, na zarovnanie medzera:) plne suhlasim a som rad, ze si dal odkaz na clanok, ktory potvrdzuje moje tvrdenie:)
odsadzovaniu zdar, zarovnaniu zvlast:D
-
http://www.hackles.org/cgi-bin/archives.pl?request=284
-
nepoužívat Tab, ale mezery. Důvod byl řečen výše - při použití jiného nastavení šířky tabulátoru, než jaké použil autor, se pak formátování řádek s různými úrovněmi odsazení rozpadá.
Rozpadat se to začne právě ve chvíli, kdy se odsazuje mezerami a jeden odsazuje čtyřmi, druhý osmi a třetí třeba dvěma. Pak je každý řádek odsazený jinak, podle toho, kdo ho zrovna měnil.
Zatímco když se použijí tabulátory, každý může mít nastavenou jejich šířku podle svých preferencí, ale to je jen vizuální záležitost - v souboru je uložena sémantická informace (počet úrovní odsazení) a ta dává smysl. Kód si pak můžeš roztáhnout nebo zhustit, aby se ti to líp četlo pouhým nastavením editoru.
-
Jak už to tu padlo: na odsazování úrovní jednoznačně tab (každý ať si ho nastaví na svoji velikost), na zarovnávání jednoznačně mezera.
-
je jedno ktere se pouzije, dulezite je mit jasne pravidlo v tymu.
-
je jedno ktere se pouzije, dulezite je mit jasne pravidlo v tymu.
Jednota je určitě zásadní, ale taby na odsazování mají jednoznačné výhody: umožňují volitelný vzhled a mohou zrychlovat úpravy, kdežto mezery se vyplatí pouze tehdy, když programujete na kila (na to jsou pak ale ještě lepší metody) :) :) :)
-
Já jsem taky jednoznačně pro taby, teď mě ale napadl jeden eventuální problém při práci v týmu.
Pokud člověk používá automatický formátovač kódu (v Eclipse, NetBeans apod.), tak když budu mít nastavenou stejnou šířku řádku (třeba těch klasických 80) jako kolega, ale budu mít jinou šířku tabulátorů (on např. 2, zatímco já 4), tak ve chvíli, kdy použiju ctrl+shift+F, tak se mi řádky natáhnou do šířky a některé delší se v důsledku toho zalomí.
Proto je potřeba mít v týmu jednotné nastavení formátovače nejenom ve smyslu tab vs. space, ale i u šířky řádku a šířky tabulátorů.
-
Já jsem taky jednoznačně pro taby, teď mě ale napadl jeden eventuální problém při práci v týmu.
Pokud člověk používá automatický formátovač kódu (v Eclipse, NetBeans apod.), tak když budu mít nastavenou stejnou šířku řádku (třeba těch klasických 80) jako kolega, ale budu mít jinou šířku tabulátorů (on např. 2, zatímco já 4), tak ve chvíli, kdy použiju ctrl+shift+F, tak se mi řádky natáhnou do šířky a některé delší se v důsledku toho zalomí.
Proto je potřeba mít v týmu jednotné nastavení formátovače nejenom ve smyslu tab vs. space, ale i u šířky řádku a šířky tabulátorů.
cece, to ale nema ziadny vplyv na skutocny obsah ulozeneho suboru. to je len "takto ti to ide ukazuje" :) ine je to uz s ostatnymi vecami typu "zatvroka na rovnaky riadok" alebo "medzery okolo zatvoriek" a pod. toto uz musite mat jednotne. ale zobrazovanie tabu u teba na 4 a u kolegu na 8 s tym nema nic spolocne. to nema najmensi vplyv:)
stale teda vedu taby:D pokial sa bavime cisto o odsadzovani zaciatku riadku a o nicom inom:)
-
Takže asi bych to viděl takhle ;-)
http://www.hackles.org/cgi-bin/archives.pl?request=284
Nicméně tento argument neberu:
Rozpadat se to začne právě ve chvíli, kdy se odsazuje mezerami a jeden odsazuje čtyřmi, druhý osmi a třetí třeba dvěma. Pak je každý řádek odsazený jinak, podle toho, kdo ho zrovna měnil.
Pokud někdo není schopen přizpůsobit se code-style použitého v projektu (a není to jen odsazování), neměl by do něj raději vůbec přispívat.
-
http://www.hackles.org/cgi-bin/archives.pl?request=284
asi som debil, ale ani po 15 minutach lustenia a citania textu pod obrazkom som to nepochopil:D vysvetlite niekto:) dik
-
Já jsem taky jednoznačně pro taby, teď mě ale napadl jeden eventuální problém při práci v týmu.
Pokud člověk používá automatický formátovač kódu (v Eclipse, NetBeans apod.), tak když budu mít nastavenou stejnou šířku řádku (třeba těch klasických 80) jako kolega, ale budu mít jinou šířku tabulátorů (on např. 2, zatímco já 4), tak ve chvíli, kdy použiju ctrl+shift+F, tak se mi řádky natáhnou do šířky a některé delší se v důsledku toho zalomí.
Proto je potřeba mít v týmu jednotné nastavení formátovače nejenom ve smyslu tab vs. space, ale i u šířky řádku a šířky tabulátorů.
cece, to ale nema ziadny vplyv na skutocny obsah ulozeneho suboru. to je len "takto ti to ide ukazuje" :) ine je to uz s ostatnymi vecami typu "zatvroka na rovnaky riadok" alebo "medzery okolo zatvoriek" a pod. toto uz musite mat jednotne. ale zobrazovanie tabu u teba na 4 a u kolegu na 8 s tym nema nic spolocne. to nema najmensi vplyv:)
stale teda vedu taby:D pokial sa bavime cisto o odsadzovani zaciatku riadku a o nicom inom:)
Vliv to má ve chvíli, kdy si vycheckoutu nějaký soubor, upravím v něm jednu metodu a použiji formátovač. I když jeho autor měl šířku řádky nastavenou taky na 80, ale tabulátor na 2 mezery, zatímco já ho mám na 4, tak se po použití formátovače stane to, že některé řádky, které se u něj těsně vešly do limitu 80 znaků, u mě najednou těch 80 přesahují.
Takže všechny takové řádky se najednou zalomí a já když chci dát commit, tak mám najednou v diffu kromě toho, co jsem skutečně upravil, celou řadu rozdílů způsobených přibyvšími konci řádků. A něco takového nemá v commitu co dělat.
-
Vliv to má ve chvíli, kdy si vycheckoutu nějaký soubor, upravím v něm jednu metodu a použiji formátovač.
Vy doopravdy pouštíte na cizím projektu svůj formátovač který není nastavený podle pravidel toho projektu?
-
Takže všechny takové řádky se najednou zalomí
Ty používáš formátovač, co sám zalamuje řádky?
-
Vliv to má ve chvíli, kdy si vycheckoutu nějaký soubor, upravím v něm jednu metodu a použiji formátovač. I když jeho autor měl šířku řádky nastavenou taky na 80, ale tabulátor na 2 mezery, zatímco já ho mám na 4, tak se po použití formátovače stane to, že některé řádky, které se u něj těsně vešly do limitu 80 znaků, u mě najednou těch 80 přesahují.
Takže všechny takové řádky se najednou zalomí a já když chci dát commit, tak mám najednou v diffu kromě toho, co jsem skutečně upravil, celou řadu rozdílů způsobených přibyvšími konci řádků. A něco takového nemá v commitu co dělat.
stale nerozumiem, co to s tym ma? pocet \t na zaciatku riadku sa nezmeni, skutocny format riadka tiez nie. cize sa de facto nezmeni nic. ale pokial tam mas takych idiotov, co si nastavia ide tak, ze zalamuje riadky pomocou \n, tak sa necuduj. to je debilita kodera, nie nevyhoda tabu:)
po dalsie, nastav si poridne verzovaci nastroj, aby nebral do uvahy zmenu vo whitespace:) co ti mam na to povedat?
-
Nicméně tento argument neberu:
Rozpadat se to začne právě ve chvíli, kdy se odsazuje mezerami a jeden odsazuje čtyřmi, druhý osmi a třetí třeba dvěma. Pak je každý řádek odsazený jinak, podle toho, kdo ho zrovna měnil.
Pokud někdo není schopen přizpůsobit se code-style použitého v projektu (a není to jen odsazování), neměl by do něj raději vůbec přispívat.
Souhlasím - o tom ale ten spor není - můj předřečník kritizoval tabulátory, že při různém nastavení rozbíjejí kód - tak jsem psal tohle jako důkaz, že to není pravda a že je to přesně naopak. Při stejném nastavení funguje oboje. Při odlišném nastavení rozbíjí odsazování mezerami kód, protože každý odsadí o jiný počet mezer - zatímco jinak nastavené tabulátory jsou jen záležitost zobrazení v daném editoru daného vývojáře a uložené v souboru vypadají stejně.
cece, to ale nema ziadny vplyv na skutocny obsah ulozeneho suboru. to je len "takto ti to ide ukazuje" :) ine je to uz s ostatnymi vecami typu "zatvroka na rovnaky riadok" alebo "medzery okolo zatvoriek" a pod. toto uz musite mat jednotne. ale zobrazovanie tabu u teba na 4 a u kolegu na 8 s tym nema nic spolocne. to nema najmensi vplyv:)
Pokud se zalamují řádky na nějakém počtu znaků, tak to vliv mít může, ale to je jedno, protože když už se používají automatické formátovače, je potřeba vynutit v týmu všude stejné nastavení (společný konfigurační soubor/volby editoru/IDE). Tabulátory tak jako tak vedou.
...formátovač, co sám zalamuje řádky?
To je celkem běžné, že to formátovač umí, ale spíš mi přijde, že zalamování na nějaké natvrdo dané šířce je přežitek. Terminály se pro vývoj používají už málokde a běžný monitor programátora poskytuje na šířku místa víc než dost.
-
Pokud se zalamují řádky na nějakém počtu znaků, tak to vliv mít může, ale to je jedno, protože když už se používají automatické formátovače, je potřeba vynutit v týmu všude stejné nastavení (společný konfigurační soubor/volby editoru/IDE). Tabulátory tak jako tak vedou.
netvrdim, ze to vplyv nema, pokial sa tam vlozi \n. tvrdim, ze to vplyv nema, pokial to ide tak iba zobrazi. mozno som z inej planety, ale ktore ide zalamuje tak, ze si svojvolne niekam supne \n? dokonca ani moj netbeans to nerobi:D iba dlhy riadok cez najblizsiu pouzitelnu medzeru pre mna zobrazi na novom riadku, ale nevklada tam znaky, ktore ja svojpravne nestlacim na klavesnici, alebo pokial nespustim formatovac:)
alebo si nerozumieme?:)
-
netvrdim, ze to vplyv nema, pokial sa tam vlozi \n. tvrdim, ze to vplyv nema, pokial to ide tak iba zobrazi. mozno som z inej planety, ale ktore ide zalamuje tak, ze si svojvolne niekam supne \n? dokonca ani moj netbeans to nerobi:D iba dlhy riadok cez najblizsiu pouzitelnu medzeru pre mna zobrazi na novom riadku, ale nevklada tam znaky, ktore ja svojpravne nestlacim na klavesnici, alebo pokial nespustim formatovac:)
alebo si nerozumieme?:)
Ale jo, rozumíme :-) Jak byla řeč o formátovačích, tak jsem bral ten případ, že vkládá \n (BTW: Netbeans to dělat můžou, když si je tak nastavíš). A souhlas i v tom, že natvrdo zalamovat v kódu je (většinou) blbost resp. přežitek.
-
Ale jo, rozumíme :-) Jak byla řeč o formátovačích, tak jsem bral ten případ, že vkládá \n (BTW: Netbeans to dělat můžou, když si je tak nastavíš). A souhlas i v tom, že natvrdo zalamovat v kódu je (většinou) blbost resp. přežitek.
ved o tom pisem. ak si ich tak nastavis:) to s tabmi nema nic, to je o blbosti uzivatela ide:)
svojvolne zalamovanie editorom je vzdy blbost:) ak zalamuje vedome sam autor, na tom nic neni. predsa len, niektori si radi svoje kody aj tlacia:D hehe. a ak to ma aj na papieri vyzerat dobre, musis to jednoducho zalomit. ale len ty a nie editor:)
takze sa mozme kludne zhodnut a temu zrejme uzavriet, ze:
- na odsadzovanie zaciatku riadku 'tab'
- na zarovnanie bloku textu 'medzera'
- ostatne formatovanie vsetci rovnako podla dohody
co ty na to?
-
pecko:
Formátovač v Eclipse nebere tabulátor ve vztahu k šířce řádky jako jeden znak (\t), ale jako sekvenci znaků zadané délky, takže pokud mám řádku nastavenou na 80 znaků a tabulátor na 4, tak se na ní vejde 20 tabulátorů, ne 80. A pokud řádka přesahuje přes limit, tak jí formátovač prostě v určitém místě rozdělí pomocí \n. Možná je to pro někoho neobvyklé, ale Eclipse opravdu soft zalamování (bez vkládání konců řádek) neumí. Ignorovat změny ve whitespace v diffu (alespoň u SVN klienta v rámci Eclipse) samozřejmě jde, ale to bere v potaz jenom mezery a taby, ale konce řádků to ignorovat asi neumí.
salam:
Třeba eclipsí editor pro Scalu mám pocit na konce řádků nešahá vůbec, ani je nepřidává, ani neubírá. Scala mi ale v tomhle přijde oproti Javě trochu specifická, protože jednak moc nehrozí, že by člověk psal moc dlouhé řádky (i když některé deklarace ve standardní knihovně jsou šílené) a mi přijde, že Scala je pokud jde o styl psaní dost volná, protože umožňuje zapsat jednu věc spoustu různě stručnými způsoby. Třeba místo:
def avg(x, y) = {
(x + y) / 2
}
jde napsat:
def avg(x, y) = (x + y) / 2
A podobně s closures, case bloky apod., podle potřeby to můžu loupnout přímo do jedné řádky anebo rozdělit na víc řádků a odsadit, takže nějaké automatické zalamování by nebylo moc ku prospěchu. Na druhou stranu, v Javě jsou konvence tak nějak zažité a je v běžné praxi skoro jednoznačné tu metodu napsat takhle (Allman style už je doufám přežitý):
int avg(int x, int y) {
return (x + y) / 2;
}
a ne:
int avg(int x, int y) { return (x + y) / 2; }
Defaultní nastavení v Eclipse konce řádků agresivně přidává i odebírá, což mě osobně nevyhovovalo, protože nebylo možné si podle sebe rozdělit jeden příkaz na víc řádků, takže aktuálně to mám nastavené tak, že příliš dlouhou řádku může zalomit, ale existující konce řádků smazat nemůže. Jinak bych nemohl napsat třeba něco takovéhohle:
int result = someCondition
? getResultA()
: getResultB();
-
Teda vaše problémy bych chtěl mít...
-
Space rulezzz!!!
(http://25.media.tumblr.com/tumblr_kt5xzwfX7y1qart38o1_500.jpg)
-
Myslím, že záleží na spoustě věcí: Například na použitém jazyce a konkrétním projektu... Já například pro osobní účely používám v shellu jiné konvence než v pythonu a jiné zase v c. Když ale budu chtít přispívat do nějakého existujícího většího projektu (jako je třeba linuxové jádro), pravděpodobně nejdříve začnu tím, že si nastuduji code style, který se v daném projektu používá, než začnu něco patlat..
-
- na odsadzovanie zaciatku riadku 'tab'
- na zarovnanie bloku textu 'medzera'
- ostatne formatovanie vsetci rovnako podla dohody
Tak to používám taky:
namespace Neco {
⇥class NecoJineho {
⇥⇥NecoJineho(int prvniArgument,
⇥⇥ int druhyArgument)
⇥⇥{
⇥⇥⇥log("HERE");
⇥⇥}
⇥};
}
-
- na odsadzovanie zaciatku riadku 'tab'
- na zarovnanie bloku textu 'medzera'
- ostatne formatovanie vsetci rovnako podla dohody
Tak to používám taky:
namespace Neco {
⇥class NecoJineho {
⇥⇥NecoJineho(int prvniArgument,
⇥⇥ int druhyArgument)
⇥⇥{
⇥⇥⇥log("HERE");
⇥⇥}
⇥};
}
Jenže zrovna tento způsob mixování tabulátorů a mezer je nejlepší cesta, jak kód zprasit, protože:
- sebelepší IDE nepozná, kde chcete mít tabulátory, a kde mezery,
- musíte mezery (na rozdíl od tabulátorů) psát ručně, a cokoliv prováděného ručně, krom toho, že je to silně nepohodlné, je potenciální zdroj chyb,
- můžete si sice tabulátory nechat zobrazit, jenže to znepřehledňuje kód → potenciální zdroj chyb,
- a stejně byste museli neustále kontrolovat, jestli máte tabulátory a mezery na správném místě – odpoutává to pozornost od psaní samotného kódu → opět potenciální zdroj chyb,
- pokud někdo nový bude přispívat do kódu, koukne se, zda se používají tabulátory, nebo mezery, a náhodou se strefí zrovna do míst, kde je použito jen jedno, tak bude předpokládat, že je to použito v celém kódu. Uznávám, sám neschopnost programátora v předchozí argumentaci neberu jako omluvu, nicméně zde je to odůvodnitelné ;-)
Proto tabulátory ne!
-
Tak to používám taky:
namespace Neco {
⇥class NecoJineho {
⇥⇥NecoJineho(int prvniArgument,
⇥⇥ int druhyArgument)
⇥⇥{
⇥⇥⇥log("HERE");
⇥⇥}
⇥};
}
Tak se to zrovna nepoužívá.
{ a } jsou od toho aby uvozovaly blok, takže by měly být zarovnány do bloku tedy pod sebou, takhle se musí půl hodiny luštit co k čemu patří, zvláště když blok má mnoho řádků. Když jsou { a } pod sebou, je to na první pohled jasné jako facka.
camelCase je nastražená mina, která fantasticky zesložiťuje hledání bugů nad ránem když pozornost klesá, popřípadě když se spěchá. Vrchol této blbosti je mít dva a více stejných identifikátorů rozlišených jenom velikostí některého písmene.
Zarovnávání tabelátory je nic než zvěrstvo, protože každý má nastavenou jinou velikost tabelátorů, takže různí lidé stejný kód vidí různě a hlavně do kódu lezou a dělají úpravy, takže po chvíli nevyhnutelně vznikne guláš, který by se s mezerami nikdy nestal.
-
Tak se to zrovna nepoužívá.
{ a } jsou od toho aby uvozovaly blok, takže by měly být zarovnány do bloku tedy pod sebou, takhle se musí půl hodiny luštit co k čemu patří, zvláště když blok má mnoho řádků. Když jsou { a } pod sebou, je to na první pohled jasné jako facka.
Pokud má blok mnoho řádků je něco špatně v kódu a žádný styl formátování si s tím neporadí.
Zarovnávání tabelátory je nic než zvěrstvo, protože každý má nastavenou jinou velikost tabelátorů, takže různí lidé stejný kód vidí různě a hlavně do kódu lezou a dělají úpravy, takže po chvíli nevyhnutelně vznikne guláš, který by se s mezerami nikdy nestal.
Tabulátor je jenom jeden znak a to jak je velký se do zdrojáku neukládá. Ten guláš naopak vznikne s mezerami pokud každý odsazuje různým počtem mezer.
-
Tak se to zrovna nepoužívá.
{ a } jsou od toho aby uvozovaly blok, takže by měly být zarovnány do bloku tedy pod sebou, takhle se musí půl hodiny luštit co k čemu patří, zvláště když blok má mnoho řádků. Když jsou { a } pod sebou, je to na první pohled jasné jako facka.
To se používá úplně běžně. To k čemu spodní } patří dohledáš úplně jednoduše podle odsazení a nemáš pak prázdný řádek jen s { .
camelCase je nastražená mina, která fantasticky zesložiťuje hledání bugů nad ránem když pozornost klesá, popřípadě když se spěchá. Vrchol této blbosti je mít dva a více stejných identifikátorů rozlišených jenom velikostí některého písmene.
Mohl bys uvézt nějaký případ, ve kterém je použití camelCase zesložitěním? Použití rozdílných počíátečních písmen nepočítám. Na to mají existovat konvence v rámci projektu, které se mají dodržovat.
-
Jenže zrovna tento způsob mixování tabulátorů a mezer je nejlepší cesta, jak kód zprasit, protože:
- sebelepší IDE nepozná, kde chcete mít tabulátory, a kde mezery,
KDevelop to pozná (bloky jsou odsazené tabulátory, uvnitř závorek se to dorovnává mezerami pod sebe), AFAIK vim tak jde taky nastavit
- musíte mezery (na rozdíl od tabulátorů) psát ručně, a cokoliv prováděného ručně, krom toho, že je to silně nepohodlné, je potenciální zdroj chyb,
Nemusím, když IDE pozná, kde má být co
- můžete si sice tabulátory nechat zobrazit, jenže to znepřehledňuje kód → potenciální zdroj chyb,
Mám je zobrazené a nevšiml jsem si, že by to znepřehledňovalo kód. Ale taky nepoužívám jako IDE MS Word.
- a stejně byste museli neustále kontrolovat, jestli máte tabulátory a mezery na správném místě – odpoutává to pozornost od psaní samotného kódu → opět potenciální zdroj chyb,
Protože KDevelop to tak umí formátovat, tak nemusím. Navíc není problém mít skript, který to kontroluje (a opravuje) třeba při pushnutí.
- pokud někdo nový bude přispívat do kódu, koukne se, zda se používají tabulátory, nebo mezery, a náhodou se strefí zrovna do míst, kde je použito jen jedno, tak bude předpokládat, že je to použito v celém kódu. Uznávám, sám neschopnost programátora v předchozí argumentaci neberu jako omluvu, nicméně zde je to odůvodnitelné ;-)
Od toho je potřeba mít coding style sepsaný. Ostatně úplně stejně se může podívat zrovna někam, kde se coding style z nějakého důvodu nedodržuje (třeba protože je to kód z cizí knihovny).
{ a } jsou od toho aby uvozovaly blok, takže by měly být zarovnány do bloku tedy pod sebou, takhle se musí půl hodiny luštit co k čemu patří, zvláště když blok má mnoho řádků. Když jsou { a } pod sebou, je to na první pohled jasné jako facka.
Vždyť jsou pod sebou. A na to, co patří k sobě, se přece pozná i podle toho odsazení.
camelCase je nastražená mina, která fantasticky zesložiťuje hledání bugů nad ránem když pozornost klesá, popřípadě když se spěchá. Vrchol této blbosti je mít dva a více stejných identifikátorů rozlišených jenom velikostí některého písmene.
Pokud se to liší velikostí prvního písmene, tak je to dané konvencí (např. třída × proměnná). Pokud se to liší někde jinde, tak programátor velmi pravděpodobně nedodržuje coding style.
Zarovnávání tabelátory je nic než zvěrstvo, protože každý má nastavenou jinou velikost tabelátorů, takže různí lidé stejný kód vidí různě a hlavně do kódu lezou a dělají úpravy, takže po chvíli nevyhnutelně vznikne guláš, který by se s mezerami nikdy nestal.
Tak si zkuste zobrazit ten můj kód s tabulátorem o délce 2, 3, 4, 8 nebo i úplně jiného počtu mezer a uvidíte, že se akorát mění hloubka odsazení (různí lidé mají různou potřebu, jak má být to odsazení velké), jinak všechno zůstává zarovnáno hezky pod sebou
-
Tady už se řeší i case a bloky? :-D Ještě se můžete pohádat o mezeru na začátku a konci výrazu, vynechávání {} za if/for/whlie, returny v těle funkce, jmenné konvence, zanořování, použití výjimek a dobře se dá zaflamovat třeba okolo stylu psaní komentářů. Kde existují sepsané konvence, tam je potřeba se jimi řídit a jinak to každýmu může být ukradený - co programátor a jazyk, to jiný styl zápisu, takže nemá smysl ten svůj(samozřejmě ten správný) nutit ostatním.