Ha indentálás, akkor

Címkék

tab ("\t") - látsszon 2 space-nek
6% (30 szavazat)
2 space
13% (65 szavazat)
tab ("\t") - látsszon 4 space-nek
38% (188 szavazat)
4 space
19% (93 szavazat)
tab ("\t") - látsszon 6 space-nek
1% (6 szavazat)
6 space
0% (1 szavazat)
tab ("\t") - látsszon 8 space-nek
5% (24 szavazat)
8 space
0% (0 szavazat)
tab ("\t") - látsszon 10 space-nek
0% (0 szavazat)
10 space
0% (0 szavazat)
1 space
0% (2 szavazat)
Egyéb, leírom hozzászólásban
4% (22 szavazat)
Nem programozok / nem tudom mi az az indentálás
14% (69 szavazat)
Összes szavazat: 500

Hozzászólások

Valójában "Use the source Luke!" elven igyekszem követni az előző programozó(k) által használt módszert.

Mi az eljárás, ha olyan forrással kerülsz szembe, ahol az egyik fügvény 2 space-es indentálást használ, a másik függvény tab-osat, és véletlenszerűen váltogatják egymást? Mi a helyzet akkor, ha egy függvényen belül hol tab, hol space van? :)
(Takarítottam indiánok után, csak azért merült fel.)
--
"Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live." John F. Woods

Get dropbox account now!

3 space

--
"Tudom én hogy nem biztonságos, de le van szarva az egész [...] A WoW jelszavam maradjon titokban csak az a lényeg!" (BlinTux)

Egyéb: leszarom hogy hogyan van megoldva, látszódjon négynek. Többit oldja meg az IDE, azért van.

Egyébként célszerűbbnek találom a tabot, mert azt bárki arra állítja, amire akarja.

Viszont régen Pascal/Delphi alatt 2 karaktert használtam.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

1, Ha valaki hülye, akkor neki hivatalból szabad nem felfogni.
2, Vagy az elmélet kitalálója ..., és akkor hivatalból nem kell felfogni.

Szóval, ha nem tapasztaltál olyat, nem tudsz róla, akkor kizárt?

Azt kéne felfogni, hogy az élet sosem olyan egyszerű, mint néhány hozzászóló.

Hogy a témához is hozzászóljak, én mindig szóközt használok, és kerülöm a tab-ot. Ami valóban felesleges szabály, ha egy IDE-t használunk, de ez nincs mindig így. Nekem vannak olyan forrásaim, amik régebbiek, mint a jelenleg használt IDE. Van olyan fejállományom, amit használ egy Qt-s GUI (ami ráadásul multiplatform), és egy mikrokontroller C programja, nem ugyan az az IDE. Vannak script-ek is amikhez nem használok IDE-t, csak legalább 4 féle text editort, ami éppen van a gépen. Nincs mindegyik ugyanúgy beállítva, és nem is biztos, hogy értelmezettek mindnél az ilyen jellegű beállítások.

És ha lehet állítani, akkor mi-van. A saját gépemen, be szoktam állítgatni editort, IDE-t, de sok géppel van ám dolgom. Az se biztos, hogy azt én állítottam be, vagy én választottam editort, IDE-t. És ekkor sem szeretem, ha bemásolom a szarjaimat, és szétesik az indentálás, ha valamiért bele kell nézni.
Az rendben, hogy ennek nincs jelentősége egy jól belakott környezetben, de mi van, ha ez nem adott. És olyan is van ám, hogy változik a környezet valamiért. Nekem még nem volt abból bajom, ha szóközt használtam, a tabokkal már igen.
Úgy tűnik, nem egyezik a véleményünk, hogy ki teszi a hülyét.
Amúgy pedig a véleményemet írtam le, amit nem muszáj elfogadni, és veled ellentétben emiatt még hülyének sem foglak nézni (a stílus miatt levont következtetéseim pedig nem tartoznak a témához).

CSS-be: tab-size: 4 - illetve korabban pre {-moz-tab-size: 4;} kellett.
(nalam user css-be kerult be, a review feluleten nem akartak modositani akkor meg)

Ha egy file-on (plane egy soron!) belul van tab es space is, akkor meg szolni kell a gazdinak, hogy tegye tisztaba mielott commitolja. Tobbek kozt errol is szol a review.

Egyebkent pont az eltero szelesseg miatt kerulom a tabot, sajat programban fixen 2 space a behuzas, mas letezo kodjaba meg blend-in elvvel (ahogy az adott file-ban/modulban/projectben van).
{}-nel ugyanez: ha sajat kod, a { es } egymas fole kerul, ha mase, akkor blend-in.

Az, hogy igy szintenkent 1-1 byte-tal nagyobb (1 tab helyett 2 space), nem izgat, tomoritve plane nem.

--
What's worse than finding a worm in your apple?
Finding a U2 album on your iPhone.

"Indent with tabs, align with spaces" elv híve vagyok, szerintem jól működik.

A behúzásnál a tab 1 egység, tök mindegy milyen szélesen jelenik meg, az igazításnál ahol fontos hogy egymás alatt megfelelő pozícióban legyenek tartalmak ott pedig szóköz.

Nem érdekel, rábízom az IDE-re, hogy formázza magától, a beállítás meg az adott projekten, munkahelyen múlik. Visual Studiónak vannak defaultjai, ott pl. C#-ban 4 space (de XML-ben 2 space). Google Java style guide Eclipse-be betöltve 2 space. A tab-bal sincs bajom amúgy, sokáig dolgoztam tab-ra állított Visual Studióval.

--

Félreértettél. Engem azért nem érdekel, mert az IDE megformázza magától. A csapat összes tagja egyforma IDE beállítást használ. Tehát extra munka nélkül magától ugyanúgy fog kinézni. A csapat többi tagja sem a formázással bajlódik.

Pont akkor lenne baj, ha minden ember kézzel formázgatna. Jobb IDE esetében tab/space nyomogatás sem kell, a { karakter hatására már magától bentebb ugrik a kurzor. Aki cat-tel és hasonlókkal programozik, az persze úgy járt.

--

Attól függ. Makefile-ban szerintem megesik az emberrel, hogy a tabot tabnak szeretné meghagyni.

4 space, amúgy láttam már olyan mixet, hogy tab, látszódjon 8-nak, közben meg space-szel pótolva, de maga az indentálás 4.

Legtöbbször mcedit-tel írok scripteket, ott így használom. A TAB billentyű mod 4 = 0-ra pozícionál, viszont minden második ilyen pozíció esetén a tabulátor kódját használja, köztes helyeket szóközökkel egészíti ki. Tehát pl. a 12-es pozíció kezdődik egy tabulátorral, folytatódik 4 szóközzel.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Pythont tanulom, négy space a default behúzás. Miért? Csak. Lehetne tab is, a lényeg, hogy akkor végig, következetesen az legyen.
Mivel vimet használok, így oldottam meg a hordozhatóságot:


#!/usr/bin/env python
# -*- coding: utf-8 -*-

"""
Python template
"""

# vim: tabstop=4 expandtab shiftwidth=4 softtabstop=4

Ave, Saabi.

Ott meg van más gond. Nekem a behúzás mint blokk meghatározó szintaktika jobban megfelel, mint a pontosvesszők és kapcsoszárójelek alkalmazása. Igaz, én COBOL-on nőttem fel, ott meg már az se mindegy, hogy melyik oszlopba mit írsz. (ez igazából csak a sorok elejére igaz) Viszont ezzel rákényszerítenek, hogy olvasható kódot gyárts. ( persze még mindig kibaszhatsz a kollegákkal, ha például O00O0, OO00, O0O0, etc... változóneveket használsz :-) )

Ave, Saabi.

Teljesen mindegy.
Leginkabb tab, aztan ki hogy allitja be, hogy az mekkora behuzas.
Space(ek) is lehetnek, amig jol atlathato, nem ezen fog mulni.

Lazan kapcsolodik, de hatha tud ra valaki megoldast: azt az egyszeru, ugyanakkor zsenialis Emacs feature-t szeretnem tetszoleges IDE-ben (pl. Eclipse, IDEA) latni, hogy a TAB lenyomasara a sort automatikusan indentalja, _akarhol allok a soron belul_.

PyCharm-ban probaltam: Ctrl-Shift-Enter semmit nem csinal, azon kivul, hogy uj sort nyit es odaugrik (Linuxon ez a Complete current statement). Az auto-indent pedig kisse eklektikus, igaz, pont Pythonban siman nem egyertelmu, hogy mire gondolt a kolto, ha nincs rendesen indentalva, de mondjuk ismetelt nyomogatasra esetleg valtogathatna az alternativ megoldasok kozott. Becsszo, nem kotozkodni akarok ;)

Csak kovesse az eloirtakat projekten belul. Peldaul Magento: 4 space, es meg az is meg van hatarozva, hol lehet az if utan a zarojel vagy a kezdo curly bracket.

Drupal: 2 space, nagybetus TRUE, stb.

Amikor meg valaki ezeket nem veszi figyelembe, nagyon ki tudok akadni. Kedvencem, amikor az IDE defaultja belekever tabokat a space-ba.

Vagy amikor a tab nem eleg egy array() belo elemeinek indentalasara, es a hgy space-el kipotolja, amit a tab nyomkodasa nem old meg...

Javaslom, hogy mindenki telepitse es hasznalja az editorconfigot a sajat szerkesztojehez:

http://editorconfig.org/

Sajat projekteken belul 4 space-t hasznalok, mert csak. Szoval arra szavaztam.

Már a kérdés maga megmutatja, hogy a tabozás problémát tud okozni. Mit értünk azon, hogy "látsszon"???

A Pisti vimjében? Vagy a Joli eclipse-ében? Githubon? Ha sehol nem használsz igazításhoz space-t, akkor rendben is van. De ha előfordul ilyen:


int MyLittleMethod(int first, int second, float third, void* fourth,
                   int pooorFifthWrappedToSecondLine) {
// ...

Akkor cseszheted a tabjaidat. És rengeteg forráskód íródik így. A safe opció: space.

Haskellnél, pythonnál importkor jól tud jönni a tabuláris szerkesztés. Itt egy példa:


import qualified Data.ByteString.Char8 as SBC
import qualified Data.HashMap.Strict   as HMS
import           Data.List             (isInfixOf)
import           Data.Monoid           ((<>))
import qualified Data.Text             as T
import qualified Data.ByteString       as S

Egyből látod, milyen függőségek vannak. Néha persze leszarom, mert OrganizeImports azt szevasz, de ez nem mindig opció.

Nemcsak importkor jön jól, ha van block editing az editorban. Segít kiszűrni a hibákat is. Sajnos bár léteznek jobb megoldások, bizonyára mindenki belefutott már ilyesmibe:


if (myVar2 < 3 && myOtherVar == OK) { doThreeThis(); }
else if (myVar1 < 5) { doFiveThis(); }
else if (myVar1 < 100) { doHundredThis(); }
else if (myVar1 < 1000*1000) { doThreeThis(); }

Látod a két hibát? Persze, hogy nem. Próbáld meg így:


if      (myVar2 < 3 && myThreeVar == OK)  { doThreeThis(); }
else if (myVar1 < 5)                      { doFiveThis(); }
else if (myVar1 < 100000)                 { doThousandThis(); }
else if (myVar1 < 1000*1000)              { doThreeThis(); }

Egyből kiszúrod, hogy véletlenül egy helyen myVar2-t írsz myVar1 helyett. Illetve doMillionThis helyett is doThreeThis lett. Ezek szemantikai hibák, nincs az az editor, ami figyelmeztetne (btw. de van, de ez offtopik). Megjegyzés: tudom, hogy ez nem a legszebb kód. De nem mindig te írod a kódot, néha kapod, és a git commitban nem akarsz stílust javítani egy bugfixért ugyebár.

Hogy fair legyek: van ennek is drawbackje:
1) szar editorban nem tudsz blokkosan szerkeszteni. Megoldás: normális editor.
2) verziókezelőben nemcsak a fentihez hozzáadott egy sor, hanem a hozzáigazítás miatt a többi is változhat (csak whitespace-ek). Megoldás:

git diff -w

Tabuláris szerkesztéskor tehát egyetlen opció: space.

Sok projektben megvan adva maximum kódszélesség. És ha tabozol? Akkor a 120 karakteres jobb határ az 4 karakteres, vagy 2, vagy 3, vagy esetleg 8 karakteres tabra van kitalálva?

A mindenhol konzisztens opció: space.

A tabozásnak egy modern editorban már nincs semmi előnye. Példa: A tab 8-ra van állítva, már gépeltem két karaktert, lenyomom a tabot, beilleszt 6 karaktert. Ha unindentálni akarok, tabszélesség egységenként tudom ezt is tenni. De ha még át is akarok térni tabokra, vagy vissza space-ekre: retab.

Hátránya viszont annál több, mint azt láthattuk a fenti példákban.

Ahogy előttem is írták, kövessük a projektben meghatározott style guide-ot. Ezzel értek egyet leginkább. Főleg, ha valamilyen okos módon (pl. vim-ben modeline vagy exrc, máshol esetleg EditorConfig) be is van tartatva.

Van olyan projektem, ahol vígan space-ezek (és van hozzá modeline is, tehát véletlenül sem tudom nem betartani). Természetesen a Tab leütése nálam is 2,4 space-t, vagy \t karaktert szúr be. Ugyanígy az (un)indent 2,4 spacet, vagy \t-ot ad hozzá/vesz el.

A fenti kódrészletekkel egy baj van. Azt mondod, hogy az egyes elemekre tekintsünk úgy, mint egy táblázatra és a következő oszlopok indulási pozícióra igazodjon az aktuális oszlop legszélesebb oszlopához.

Na de mi van akkor, ha ezt oszlopot törlöd, mert nem kell? Vagy éppen átírod és már nem az lesz a leghosszabb? A többi kódrészt is újraindentálod? Szép dolog, csak elrontja a diff-et: olyan sorok is változnak, amelyek egyébként funkcionálisan nem módosultak. Oké, hogy a git tudja mutatni a diff-et whitespace-ek nélkül, de erre nem lehet támaszkodni: nem használni mindenki git-et és a code review eszközök sem mindig támogatják.

Én pont ezért szoktam le róla.

-----
„Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben.”
rand() a lelke mindennek! :)
Szerinted…

Leírtam, hogy lehet hátulütője. Azt is, hogy mi a megoldás. Ahogy te is.

Szerintem inkább a diff "romoljon el". Ha a diffre ránézel (git esetén -w nélkül), akkor is látható, hogy space change volt csak, és vizuálisan ki tud bukni ha hiba van. Ezt az "elromlott" diff-et két-három ember látja (a committer, és a reviewerek mondjuk), míg magát a kódot aztán 1-től 10-en át (projekttagok esetén) 100-on át (osztott lib esetén) milliókig (nyílt forrás esetén) mindenki.

Tényleg három-négy ember miatt lemondanál a többiekről? Ráadásul úgy, hogy hármuknak bár pár sorral több lesz a diff, de továbbra is vizuálisan konzisztens marad...? Érdekes.

Az ember felismer alakokat, összetételeket (ezáltal szavakat, változó- és függvényneveket), viszont amiben ezeszer jobb, már a szem is, az a különbségek felismerése. Nem véletlenül használunk táblázatokat több ezer éve. Én azt vallom, hogy ha már van szemünk és agyunk, használjuk. Ha már használjuk, használjuk hatékonyan. Miért pont kódoláskor ne? :-)

Ha jobban el szeretnél mélyedni a témában, ajánlom az ide vonatkozó irodalmat a vizuális érzékelésről. Meglepő, mennyi új dolgot tanul az ember már az első két bekezdéséből egy-egy ilyen könyvnek. (Én személy szerint ezt forgattam: http://www.amazon.com/Applied-Security-Visualization-Raffael-Marty/dp/0…)

Egyrészt az sosem baj, ha szép.
Másrészt nem a szépségen volt a hangsúly.

> Az alapvető hibák kiszűrésére unit tesz kell.
Mivel már így is sokat írogattam ide, ezért most rád bíznám a feladatot: keress statisztikákat légy szíves, a ma használatban levő szoftverek (szűkítsük mondjuk nyílt forrásúakra) össz-unitteszt-coverage-ére. :-)

Az, hogy van egy - sajnos alig használt - eszköz a hibák kiszűrésére, nem jelenti azt, hogy ne használjunk másik jó eszközt :-)

Lásd még: yoda conditions.

Attól, hogy sok szoftverhez nincs teszt, nem jelenti azt, hogy ez jó, még kevésbé azt, hogy ezt kellene elfogadni követendő példaként. Erre a problémára a blokkos kódformázás maximum placebo, és sokkal kevésbé hatékony, mint egy jól megírt unit teszt. Úgy értem, sokkal kevesebb esetben van előnye a nem blokkos formázáshoz képest. Egyébként a nem konzekvensen elnevezett metódusok, vagy a var1/var2 jellegű változónevek, amik az eredeti példában vannak, eleve kibuknak egy code review-n. Tudom, a ma használatban levő szoftvereknél ez sem feltétlenül jellemző :).

--

Amiket leirtal igazak, csak nem relevansak. Ha megfeszulsz, akkor sem fogja a developer vilag a unittesztjeidet irogatni, meg kevesbe kodreview-zni. Nezz korul githubon.

Mielott leirnad, hogy dehat ez igy nem jo, meg egy normalis projektben ez aztan nem igy van, meg te aztan nem csinalnal ilyet, meg kulonbenis... Inkabb meg egyszer elmondom: nem az a kerdes, mi az utopikus alomvilagban a jo, hanem az, hogy mi van eppen.

Es az van, hogy hiaba volt meg a kodreview, hiaba volt ott a unitteszt, mivel a ket reviewer eppen felalomban volt hatarido elott, ezert csak ott maradt a release-ben a var1/2.
A masik esetben a unitteszt meg eppen atlepte a szemantikai problemat, merthiszen a policy az, hogy 92%-os coverage felett mar jok vagyunk.

Mielott leirnad, hogy akkor a business processzekkel meg a reviewerekkel meg a managerekkel meg a joegtudja meg kivel van gond, inkabb leirom en: igazad van, de ettol meg EZ VAN.

Értem én, hogy ez van, de attól ez még a valóságnak csak egy szelete. Lehet csak nekem volt szerencsém, de eddig olyan helyeken dolgoztam, ahol sokat számít a kód minősége, kötelező review és coverage van.

Ugyanakkor te is javasolsz egy bizonyos kód formázási módszert, de ugyanúgy kétséges, hogy ez van, vagy nem ez van.

Másképpen fogalmazva, mindkettő módszert lehet használni vagy nem használni és tákolt kódot írni. Én csak annyit állítok, hogy ha valaki igényes kódot akar írni, inkább unit tesztet írjon a maradék idejében. Ha nem akar, akkor meg úgyis mindegy.

--

Van ilyen egyébként, de arra próbáltam reagálni, hogy azt mondtad, inkább legyen a \n a határoló, mert az minden sor végén ott van. És azt próbáltam mondani, hogy épp azért, mert egyébként is ott van minden sor végén -- mert a kóder üti hogy "tipográfiai" szempontból (értsd jól) szép legyen -- ezért nem szerencsés nyelvszintaktikai határolónak, mert akkor hol ez hol az, ellentétben a ;-vel, ami meg akkor van ott, mikor határolót akarsz. Szerintem zeller is ezért mondta, de aztán lehet valamit félreértek :)

A teszt nem a hibak kiszuresere van. A teszt arra van, hogy ellenorizzuk, az adott kodreszlet adott bemenetre adott kimenetet produkal-e, semmi tobbre. Hogy mennyire hibas, mennyire nem hatekony, mennyire lassu - ezt a tesztek merni nem tudjak.

A temaban ajanlott irodalom: http://csakatesztemenkeresztul.blog.hu/2011/10/04/a_teszteles_nem_minde…
--
Blog | @hron84
Üzemeltető macik

+1

Régebben azon a véleményen voltam, hogy TAB ott, ahol logikai tabulásásról van szó (ha úgy tetszik: az egymásba ágyazott kapcsos zárójelek számának megfelelően), és szigorúan csak sor elején használható; viszont a MyLittleMethod-os példádnál szóközök. És ennek megfelelően helyenként pedig jópár TAB után csomó (egy TAB-nyinál bőven több) szóköz. Másképp megfogalmazva: a forráskód tetszőleges TAB szélesség mellett nézzen ki helyesen. (De ezzel még mindig van elvi probléma, ahogy mondod, ha be kell tartani egy jobb margót.)

Az egyik nagy probléma ezzel az, hogy gyakorlatilag tarthatatlan, nehézkes.

Jópár éve viszont már azon az állásponton vagyok, hogy a TAB karakter a legtöbb vezérlő karakterhez képest nem való arra, hogy szövegfájlban tároljuk el, mint ahogyan például backspace vagy form feed karaktert sem használunk erre.

Sima szövegfájlban összesen két vezérlő karakter szokott gyakran előfordulni, az újsor (és most a CR kontra LF őrületbe se menjünk bele, az is katasztrófa) és a TAB. Namost ezekből az előbbi szükséges, a második viszont teljesen fölösleges.

A TAB kábé úgy viszonyul a szóközhöz, mint ahogyan a mostanra szerencsére gyakorlatilag kihalt FF (form feed, ^L) az újsorhoz. Metódus végére sem tesz senki manapság FF-et, és kezd el azon filózni, hogy (a TAB-szélességhez hasonlóan) a FF-et ki hány újsorra állítja be saját preferenciája szerint.

A szövegfájlnak nem a dokumentum logikai struktúrájának leírása a cél. Olyan karakter sincs, ami egy nyitó kapcsos zárójel akár a sor végén, akár a következő sor elején, a beállított preferenciák szerint. Olyan sincs, ami függvény neve után nyitó zárójel, szóközzel vagy anélkül a felhasználó ízlése szerint. Olyan sincs, ami függvényeket, osztályokat stb. választana el egymástól, konfigurálható méretű vizuális kihagyással. Miért pont a vízszintes tabulálásra kellene hogy létezzen?

A szövegfájlnak az a feladata, hogy az írógéppel leírthoz hasonlóan a konkrét tartalmat és konkrét kinézetet rögzítse.

És mint ilyen, a TAB billentyű létezése és megfelelő ASCII kód továbbításának lehetősége különféle csatornákon (pl. ssh) egészen odáig hogy elérkezik egy szövegszerkesztőig amelyik ezt látván mindenféle okosságot csinál, teljesen rendben van. De a fájlban eltárolása hatalmas indokolatlan tévedés, melybe a számítástechnika sajnos belefutott a fejlődése során és sajnos nem tud / nem akar levetkőzni.

Egyetértek veled, tetszik, ahogy metaszintre emelted az egész TAB-kérdést :) ("a TAB karakter a legtöbb vezérlő karakterhez képest nem való arra, hogy szövegfájlban tároljuk el, mint ahogyan például backspace vagy form feed karaktert sem")

Ahogy az utolsó bekezdésedben írtad, maradjunk reálisak: lesznek még tabbal indentált kódok, amibe kell contribolnunk. Én teljesen elégedett vagyok az editor segítségével. Ugyanakkor látom, hogy pár kevésbé skilles egyén elcseszi, mert csak beleindentál egy-egy ifnél space-szel, de persze rossz tabmérettel. :-(

egyeb: c/c++ 4space, ruby/lua/livescript/scala 2 space

I hate myself, because I'm not open-source.

1 tab lenyomás szúrjon be 4 space-t!

A tab nem ennyi-annyi space, hanem a következő: Megadunk egy monoton növekvő sorozatot (ennek elemei a tab-pozíciók), az első elem pozitív, a növekmény ízlés szerinti, és nem feltétlenül egyforma. A tab karakter arra ad utasítást, hogy az írás az aktuális pozíciótól jobbra eső legközelebbi tab-pozíciónál folytatódjon.

Zagyva dolog, kár volt meghonosítani az informatikában.
--
ulysses.co.hu

Es az megvan, balfaszok, hogy nem monospace-t hasznalunk az editorban, hanem proporcionalis fontot.

Ha valaki nem erti, hogy miert jo proporcionalis fonttal dolgozni, akkor az balfasz?

Nem, csak szimplan hulye hozza; ettol meg tud programozni, csak nem erti, hogy lehet monospace helyett proporcionalist hasznalni, es jobb, mert

CSAK; most minek magyarazzam. Ha ezt magayrazni kell, akkor felesleges magyarazni. Ez ertheto, marmint az indoklas? Nem? Jo. (pont, nem felkialto jel)

Megyek kakilni; most kell. (nincs osszefugges, a fentiekkel, most jott meg.)

Rábízom az IDLE-re és az Emacs-re.

Projekt függő.
A sajátoknál 4 space, Drupal moduloknál a coding standard alapján 2 space, volt munkahelyemen pedig 1 tab volt.

Még szerencse, hogy a NetBeans projektenként külön is konfigurálható.

Forráskódtól függ

- JavaScript, HTML, Python 4 space méretű tab
- (C|L|SC)SS, CoffeScript 2 space

Mindez .editorconfig tárolva, amit elvileg a legtöbb IDE ismer

Hja, kódtömörítés. Múltkor felfedeztem, hogy JavaScriptben igazából nem kellenek a sorvégi ; -k (ami tök jó, C#-ból, Javaból és minden hasonló syntaxú nyelvből is írtanám ki a francba, teljesen felesleges, ha egy sorban egy kifejezés van).

Mondom ez tök jó, .js fájlok tömörítését is mennyivel egyszerűbben le lehetne tudni így, hogy többé-kevésbé olvasható marad a kód, így egyszerűbb debugolni és nem kell mindenféle mappal szerencsétlenkedni. Erre valaki IRC-en meg akart győzni, hogy de az nem jó, mert úgy nem olyan tömör a kód. Csak tudnám mitől nem, hogy ha a ';' és a '\n' is egy byte...

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Ezt hivjak csúszós lejtőnek :)

Amúgy valóban felesleges a () az if/whilenél. A {} már kevésbé hacsak nem akarsz end [if]-eket írogatni, mert a Python indentalashoz kötöttsége szerintem is zavaró tud lenni.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

És azt szerinted lehetetlen megállapítani, hogy az adott sor végén vagy a következő elején egy operátor van? Pl.

String foo = "asdf" 
+ "jklé";

(Mondjuk stringek esetén pont nem lenne ezzel probléma, ha lenne normális multiline string, amit még PHP-ben is képesek voltak megoldani...

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Azert ez annyira nem igaz. A multi line statementek nem a pontosvesszo nelkul lesznek olvashatatlanok, hanem a szar indentalasnak koszonhetoen. A pontosvesszo ehhez semmit nem ad hozza.

Raadasul azt gondolom, hogy ha Ruby-nal meg tudtak oldani azt, hogy pontosvesszo nelkul tudok multiline statementeket irni ugy, hogy raadasul ott meg zarojelezni se kotelezo, akkor az osszes C-like nyelv is meg tudna ezt oldani. Csak hat persze a szep hagyomanyok...
--
Blog | @hron84
Üzemeltető macik

SEU-t használok, nincs tab karakter. Ha van egyáltalán értelme a behúzásnak (free rpg), akkor 3 szóközt használok.
C, java, xml, html, stb. kódra ctrl-shift-f, és nem zavar ha a diff csúnya. Mindenki használja ugyanolyan beállításokkal a kódformázót.

A TAB definíciója annó az volt, hogy a következő (8k+1)-ik pozícióra menjen a kurzor (1, 17, 25, 33 stb). Tehát 1-8 szóközzel egyenértékű, a pillanatnyi pozíciótól függően.
Nos, azóta eltelt ötven év, azóta rájöttünk, hogy a szabványok akadályozzák a kreativitást, ezért most minden Hátulgombolós Pistike azt állít be a szövegszerkesztőjében, amit akar. Éljen!

tab ("\t") - leszarom hány space-nek látszik, 2-nél azért több legyen, de ne legyen félképernyőnyi

-fs-
Az olyan tárgyakat, amik képesek az mc futtatására, munkaeszköznek nevezzük.
/usr/lib/libasound.so --gágágágá --lilaliba

Kimaradt a 0 space, ami fontos a kezdő programozók kódjának identálásához :D ;)

Ez egyebkent egy erdekes kérdés, szoftverfejlesztesben rengeteg konvencioval találkozhat az ember, legyen az indentalas vagy nevezéktan vagy akar best practicles. Es azert sokan tanulnak konyvbol, ahol azert jellemzően indentalt kod van. Ennek ellenere megis sokan annyira érzéketlenek, hogy az ilyet észrevegyék.

Másrészről meg zx spectrumon nem volt indentalas basicben :P Pascalban meg átvettem a könyvből, amibol tanultam.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Nyelvfuggo, minden nyelvnek megvannak a konvencionalis standardjai, igyekszem kovetni. Pythonban, C-like nyelvekben (PHP, Perl, C, C++. C#, CSS, JS, stb.), XML-szeru nyelvekben (XML, HTML) valamint VB.NET-ben 4 space, mindenhol masutt ket space. De ha mas indentalasu koddal dolgozok, akkor igyekszem igazodni az elottem kodolohoz, kiveve, ha ez nem lehetseges az otletszeru indentalasok miatt, ilyenkor astyle-lal atformazom az erintett kodot (amugy is biztonsagi mentek elotte), es tajekoztatom a fejlesztot, hogy mi lett az uj style, es hogy tartsa be, ha azt akarja, hogy segitsek neki a tovabbiakban is.

Sajnos az astyle meg mindig nem eleg okos (bizonyos PHP-s nyelvi konstrukciok komoly fejtorest okoznak neki), de a POSIX-os indent-et sose szerettem, szamomra bonyolult.

A TAB-os kodokat nem szeretem annyira, mert en neha csak cat-tal kinyomok egy kodot, es a konzolon bizony 1 TAB = 8 space, es onnantol nehez olvasni. A space az egy konkret dolog. What you see is what you get.
--
Blog | @hron84
Üzemeltető macik

Pedig ezt a kifejezést régóta használják rá a nyomdaiparban is. Ennyit az izzadtságszagú erőltetetten fordított kifejezésekről.

Ui.: A billentyűzetet billentyűzetnek hívod? :)

-----
„Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben.”
rand() a lelke mindennek! :)
Szerinted…

A programnyelv amiben dolgozok - mellesleg elég C szerû - gyakran tartalmaz Oracle query-ket, ezért a tab nálam ki van zárva, azzal képtelenség több száz soros selectet értelmesen indentálni. A két space mellett azért döntöttünk, mert vertikálisan szeretjük olvasni a kódot, és habár optimális esetben egy függvény egy dolgot csinál, van egy-két komolyabbnak mondható (relatív) algoritmus ahol elszállt a ló.
Java-ban és javascript esetében TAB és K&R.