Tabulátor nebo mezera v kódu

pecko

  • ***
  • 105
    • Zobrazit profil
    • E-mail
Re:Tabulator vs . Space
« Odpověď #30 kdy: 07. 09. 2012, 17:16:15 »
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?:)


Franta

Re:Tabulator vs . Space
« Odpověď #31 kdy: 07. 09. 2012, 17:27:24 »
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.

pecko

  • ***
  • 105
    • Zobrazit profil
    • E-mail
Re:Tabulator vs . Space
« Odpověď #32 kdy: 07. 09. 2012, 17:37:01 »
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?

Natix

Re:Tabulator vs . Space
« Odpověď #33 kdy: 07. 09. 2012, 19:20:48 »
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:
Kód: [Vybrat]
def avg(x, y) = {
    (x + y) / 2
}
jde napsat:
Kód: [Vybrat]
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ý):
Kód: [Vybrat]
int avg(int x, int y) {
    return (x + y) / 2;
}
a ne:
Kód: [Vybrat]
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:
Kód: [Vybrat]
int result = someCondition
    ? getResultA()
    : getResultB();

Re:Tabulator vs . Space
« Odpověď #34 kdy: 07. 09. 2012, 19:59:25 »
Teda vaše problémy bych chtěl mít...


xxx

Re:Tabulator vs . Space
« Odpověď #35 kdy: 07. 09. 2012, 22:53:24 »
Space rulezzz!!!


kei.101

Re:Tabulátor nebo mezera v kódu
« Odpověď #36 kdy: 10. 09. 2012, 15:49:21 »
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..

Sten

Re:Tabulator vs . Space
« Odpověď #37 kdy: 10. 09. 2012, 16:19:04 »
- na odsadzovanie zaciatku riadku 'tab'
- na zarovnanie bloku textu 'medzera'
- ostatne formatovanie vsetci rovnako podla dohody

Tak to používám taky:
Kód: [Vybrat]
namespace Neco {
⇥class NecoJineho {
⇥⇥NecoJineho(int prvniArgument,
⇥⇥           int druhyArgument)
⇥⇥{
⇥⇥⇥log("HERE");
⇥⇥}
⇥};
}

klw

Re:Tabulator vs . Space
« Odpověď #38 kdy: 10. 09. 2012, 23:34:33 »
- na odsadzovanie zaciatku riadku 'tab'
- na zarovnanie bloku textu 'medzera'
- ostatne formatovanie vsetci rovnako podla dohody

Tak to používám taky:
Kód: [Vybrat]
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!

pkw

Re:Tabulator vs . Space
« Odpověď #39 kdy: 11. 09. 2012, 08:32:52 »
Tak to používám taky:
Kód: [Vybrat]
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.

karel

Re:Tabulátor nebo mezera v kódu
« Odpověď #40 kdy: 11. 09. 2012, 08:44:02 »
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.

Zetto

Re:Tabulator vs . Space
« Odpověď #41 kdy: 11. 09. 2012, 08:50:27 »
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.

Sten

Re:Tabulator vs . Space
« Odpověď #42 kdy: 11. 09. 2012, 10:43:55 »
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

Flame

Re:Tabulátor nebo mezera v kódu
« Odpověď #43 kdy: 11. 09. 2012, 13:00:06 »
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.