Te melyik formát részesíted előnyben? (Szavazás előtt olvasd el az első hozzászólást!)

Programozás

1. változat
28% (215 szavazat)
2. változat
28% (220 szavazat)
3. változat
42% (329 szavazat)
4. változat
2% (16 szavazat)
Összes szavazat: 780

( nevergone v | 2011. 02. 09., sze – 12:29 )

Ha többen dolgoznak egy fejlesztésen, akkor gyakran felmerülő kérdés a kód egységes formázása. Mivel az alábbi négy írásmód közül már mindegyikkel találkoztam, ezért érdekelne, hogy ti melyiket részesítitek előnyben ezek közül:

1. változat: 

if () {
}
else {
}

2. változat: 

if ()
{
}
else
{
}

3. változat: 

if () {
} else {
}

4. változat: 

if ()
{
} else
{
}

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

'undorito zarojel', lol :D
az en szememben sokkal undoritobb pl. a } else { :)
amugy ez teljesen izles dolga, kinek ez tetszik, kinek az, ezzel nincs is semmi problema
en szemely szerint a 2. verziora szavazok, mar csak azert is, mert igy egymas alatt vannak az osszetartozo zarojelek, sokkal konnyebben attekintheto, meg kicsit szellosebb a kod
meg a Pascalos idokben imadtam allat modon osszezsufolni a kodot, aztan rajottem hogy ez bizonyos hataron tul sokkal tobbet art mint hasznal
-
Slackware current / OSX Snow Leopard

( boobaa | 2011. 02. 10., cs – 09:16 )

Mindig azt, amelyik az adott projekt kódolási szabályainak megfelel.

Ez egészen addig jó, amíg írásba is foglalod, és be is tartod. Mondjuk amikor fejlesztőként dolgoztam, én kaptam azt a feladatot, hogy dolgozzam ki a kollégákkal egyeztetve a cég belső kódolási szabványait :-) A lényeg az egyeztetett, írásba foglalt (a szó elszáll...) betartható, és mindenki által betartott konvenciók legyenek többszemélyes projektek esetében. Tudom, fölöslegesnek tűnik egy-két tinglitangli programocskára az egésznél jóval nagyobb doksihalmazt legyártani, de a 123. közösen reszelt forrásfájlnál már bőven megtérül a belefeccölt munka és idő.

Szvsz. a formázási szabályokat felesleges bemagolni. Ráadásul elég terebélyes is lehet és lehetnek benne ritkán használt szabályok. Pl.: ha a sor túl hosszú és több mint 3 sorba kell törni, akkor a 3. sortól mennyi legyen a behúzás? Általában egy formázási megbeszélés erre nem terjed ki (főleg ha új). Ha ez nincs kőbe vésve akkor mindenkinél más lesz (annyi mint a 2. soré, egy indent-tel beljebb, stb.). Minek erre figyelni? Arra van a számítógép, hogy az ilyen unalmas dolgokat tartsa karban ő.

Látom nem értitek, valószínűleg nem fogalmaztam elég világosan.
_Alapvetően_ egyetértetek veletek (hisz tulajdonképpen trivialitásokat mondtok), csak azt mondom, hogy a határt meg kell húzni valahol. A példád jó: túl hosszú a sor, de mégis _hol_ törjem el a sort? Nyilván könnyedén el lehet azt törni úgy, hogy tükrözzön valamiféle logikát, ami aztán jól olvashatóvá teszi a kódot, de ha az IDE áttördeli, akkor az nagyon buta végeredményt eredményez.

+1. Ha nincs, akkor vagy a meglévő kód alapján döntöm el, hogy mit (amit addig használtak), vagy ha nulláról indul a dolog, akkor az elnevezésekkel, kommentezéssel és formázással kapcsolatban mindenképp egyeztetni kell, és az egyeztetés eredményét mindenkire kötelező érvénnyel el kell fogadtatni. Úgy a nevezéktan, mint a kötelező kommentek, illetve a formázási kérdésekkel kapcsolatban.

Az is egy valid álláspont, hogy előnyben részesítem, amit a projekt többi tagja. Bár a szavazás konkrétan nem erre irányult, de ettől még értelmes álláspont. Nem azért, mert befolyásolható vagyok, hanem mert nekem többet ér a csapatmunka, mint a saját kedvteléseim.
----
Hülye pelikán

( nanto | 2011. 02. 10., cs – 09:37 )

egyeb leirom hozzaszolasban:
if () {...;}
else {...;}

(csak ifnel es elsenel szeretem ezt, fornal kulon sor pl., fuggvenynel meg kulon sor a "}"-nek)

Ja es ha hosszabb a kodreszlet, akkor ugye elso valtozat, de egy { c=i; ++i; } befer egy sorba

( ssikiss | 2011. 02. 10., cs – 09:37 )

Ketteskét részesítem előnyben, de sajnos hármaskában kell kódolnom (munkahelyen).

( zeller | 2011. 02. 10., cs – 09:39 )

Melyik elsőt? Nálam "Beágyazott (teljes) Dátum - újabbak elöl" beállítással megy, úgyhogy momentán ez lesz az első :-P

( BlinTux v | 2011. 02. 10., cs – 09:40 )

Én mindig a 3-as megoldást választom. Viszont ha nem szükséges a {} páros, akkor azokat elhagyom:

if ()
...;
else
...;

( blueghost | 2011. 02. 10., cs – 09:42 )

Egyértelműen a második. Sosem értettem mi a jó ebben a "spóroljunk egy sort" dologban.

Attol fugg, melyikhez kepest: lehet tobb sor sporolas is :) Masreszt a 3. nekem sokkal attekinthetobb is, nem csak a sporolasrol van szo, en abbol indulok ki, hogy a { mint a blokk kezdete, az adott if-hez vagy else-hez tartozik, tehat egy sorban a helye vele. Mondjuk erdekes modon a fuggvenyek eseten kulon sorba irom ...

( egeresz | 2011. 02. 10., cs – 09:57 )


int funct( int param )
{
    int                  i;
    char                 *p;
    unsigned long long   buff[BUFFMAX];


    for(i=0; i<10; i++) {
    } /* end for i */

    if(expresion) {
    } /* end if expression */


    if(expression) {
    } else { /*  expression */
    } /* end else expression */


} /* end of funct */

ez a kedvencem. Azonban igen ritkan programozok from scratch, egyedul, inkabb messzemenokig alkalmazkodok a meglevo stilushoz.

Ez a változat nekem is bejön, szemben a meghirdetettekkel, ezért javaslom felvenni a lehetséges választási lehetőségek közé!

Ebből a változatból ugyanis az is egy szempillantás alatt kiderül, hogy a záró kapcsoszárójel mit is zár le.

Persze az is tény, hogy többletmunkát igényel a program készítőjétől, viszont nagy program esetén a hosszabb távú program karbantartást nagyban megkönnyíti.

G.
============================================
"Share what you know. Learn what you don't."

Ez nagyon olvasható, én is kb. így szoktam, plusz még ami szerintem nagyon javítja az olvashatóságot, az a "név szerinti paraméterek" C módra: 


memcpy( /* TO= */ tmp_buffer, /* FROM= */ buffer, /* SIZE= */ sizeof(char) * BUFLEN);

illetve hosszabb változónevek esetén és/vagy több argumentum esetén: 


clusters( /* graph= */      &residual, 
          /* membership= */ &NtoL, 
          /* csize= */      0, 
          /* no= */         &proj_nodes, 
          /* mode= */       STRONG       );

Na ja. De egyrészt nem mindig az editorban látod a kódot. Látod amikor patch-et küldenek neked emailen, látod a verziókezelő web-interfaceében, etc. Nem szeretném mindig megnyitni megelelő projekt fileokat és bemásolni az editorba.

Másrészt, egy mai nagy képernyőre sok kód kifér, sok ilyen függvényhívással, így egyszerre látod az összeset, anélkül, hogy végig kellene őket kattintgatni.

Egyébként szerintem a modern nyelvek abba az irányba mennek, hogy lehessen név szerint megadni argumentumokat, pl. Python. Ezzel sokkal olvashatóbb lesz a kód SZVSZ. Ha pl. van egy xycopy függvényed, akkor 


xxcopy(from=foo, to=bar);

esetén elég egyértelmű, hogy honnan és hova.

Szerk: még egy példa: 


dnaupd(integer *ido, char *bmat, integer *n, char *
       which, integer *nev, doublereal *tol, doublereal *resid, integer *ncv,
       doublereal *v, integer *ldv, integer *iparam, integer *ipntr, 
       doublereal *workd, doublereal *workl, integer *lworkl, integer *info)

10-20 argumentum esetén már elég nehéz követni, hogy mi micsoda, még ha segít is az editor.

> De egyrészt nem mindig az editorban látod a kódot. Látod amikor patch-et küldenek neked emailen, látod a verziókezelő web-interfaceében, etc. Nem szeretném mindig megnyitni megelelő projekt fileokat és bemásolni az editorba.

De, mindig editorban latom. Ha patchet kuldenek, akkor azt felrakom es ugy nezem meg, mert ugy sokkal tobb ertelme van, es onnantol rogton az editoromban latom. A verziokezelomet szinten editorbol hajtom meg, igy ott sem gond. Amin epp dolgozom, az ugyis megvan nyitva, nem kell "mindig megnyitni".

> Másrészt, egy mai nagy képernyőre sok kód kifér, sok ilyen függvényhívással, így egyszerre látod az összeset, anélkül, hogy végig kellene őket kattintgatni.

Egyreszt ahogy mas is bolcsen megjegyezte: ha sok ilyen fuggveny van kis helyen, akkor ott mar valami komolyan el van szurva.

Masreszt nem kell kattintgatnom, ha fole allok az egerrel, vagy odaviszem a kurzort, az teljesen elegendo. Megfelelo editort kell hasznalni, ennyi.

> Egyébként szerintem a modern nyelvek abba az irányba mennek, hogy lehessen név szerint megadni argumentumokat, pl. Python

Ha lehet nev szerint megadni, akkor en is szoktam neha ugy hasznalni, bar elsosorban az opcionalis parametereknel csak (a tobbibol altalaban eleve keves van, es tobbnyire logikus a sorrendjuk. Pl xxcopynal from, to sorrend eleg alap, butasagnak tartom kiirni a parameter nevet is).

> 10-20 argumentum esetén már elég nehéz követni, hogy mi micsoda, még ha segít is az editor.

Ha gagyi az editorod, akkor igen. Ha mutatja, hogy epp melyik argumentum folott allsz, akkor nem latom, hogy lenne nehez. Peldanak okaert a fenti funkcio eseteben ha elkezdem irni, hogy: 


dnaupd(intp, "blabla", np, "eztetitten",

Akkor kozben az editorom szepen tudja nekem jelezni, hogyy most az "integer *nev" nevu parameter jonne. Sot, jobb helyeken azt is viszonylag egyszeruen meg lehet oldani, hogy ha van valami standard in-code dokumentacio (pl doxygen) akkor meg a relevans dokumentaciot is meg tudja jeleniteni.

Jo editor kerdese az egesz. Nomeg ha borzalmas kodot lat az ember, mint pl a peldaban idezett fuggveny, azt nagyon gyorsan atirja, vagy minimum tokonszurja azt, aki elkovette.

--
|8]

De, mindig editorban latom. Ha patchet kuldenek, akkor azt felrakom es ugy nezem meg, mert ugy sokkal tobb ertelme van, es onnantol rogton az editoromban latom. A verziokezelomet szinten editorbol hajtom meg, igy ott sem gond. Amin epp dolgozom, az ugyis megvan nyitva, nem kell "mindig megnyitni".

Te máshogy dolgozol, mint én, ennyi. Én mondjuk 5 projekten dolgozom egyszerre, nincs mindegyik nyitva. Jön egy email egy patch-el, ehhez nem feltétlenül akarok új projektet megnyitni.

Egyreszt ahogy mas is bolcsen megjegyezte: ha sok ilyen fuggveny van kis helyen, akkor ott mar valami komolyan el van szurva.

Mármint mi? Én rövid függvényeket szeretek írni, ami azt jelenti, hogy sok függvény van, ergó sok függvényhívás is van.

Pl xxcopynal from, to sorrend eleg alap, butasagnak tartom kiirni a parameter nevet is).

Szerintem nem butaság. Ha még azt mondod, hogy felesleges, talán az rendben van, de "butaság", meg "letörném a kezét", szerintem ez meglehetősen túlzás. memcpy esetén pont fordítva van. FYI. Látod, ha kiírod a nevet, akkor ez nem fordulhat elő.

Akkor kozben az editorom szepen tudja nekem jelezni, hogyy most az "integer *nev" nevu parameter jonne.

Nem akkor van gond, amikor írod, hanem amikor olvasod. Értem, hogy akkor is fölé lehet húzni az egeret, de jobban szeretem őket egyszerre látni.

Jo editor kerdese az egesz.

Nem csak magadnak írod a kódot. Az "akkor használjanak ők is olyan editort, mint te" hozzáállás nekem nem tetszik. Szerintem, jó, ha pl. a weben is olvasható a kód.

Nomeg ha borzalmas kodot lat az ember, mint pl a peldaban idezett fuggveny, azt nagyon gyorsan atirja, vagy minimum tokonszurja azt, aki elkovette.

A példában idézett függvény az ARPACK függvénykönyvtárból van, és SZVSZ meglehetősen jó minőségű kód. A flexibilitás miatt van ennyi argumentuma, meg mert eredetileg FORTRAN.

> Te máshogy dolgozol, mint én, ennyi. Én mondjuk 5 projekten dolgozom egyszerre, nincs mindegyik nyitva. Jön egy email egy patch-el, ehhez nem feltétlenül akarok új projektet megnyitni.

Szerintem meger kb 10 secet a megnyitas + apply. Nalam legalabbis kb ennyi idot vesz igenybe, es ebben benne van, hogy a patchet lementem, mert a levelezo programom nem mindig egyezik meg az editorommal. Ha nincs kedvem/idom/lehetosegem/stb megnyitni egy uj projectet, akkor minek nezem az ahhoz tartozo patchet?

Nem tudom nalad hogy van, de szamomra fontos a kontextus, es a patchekben nem mindig van eleg, es szeretem az egeszet a maga teljessegeben latni. Ehhez pedig nagy segitseg, ha a patch fenn van (aztan legfeljebb egy masik ablakban vagy hasonloban nezem a diffet a koddal egyutt, ha epp az kell).

> Mármint mi? Én rövid függvényeket szeretek írni, ami azt jelenti, hogy sok függvény van, ergó sok függvényhívás is van.

Nem a sok fuggveny a gond, hanem a sok fuggveny trillio parameterrel.

> Szerintem nem butaság. Ha még azt mondod, hogy felesleges, talán az rendben van, de "butaság", meg "letörném a kezét", szerintem ez meglehetősen túlzás. memcpy esetén pont fordítva van. FYI. Látod, ha kiírod a nevet, akkor ez nem fordulhat elő.

Nezopont kerdese. En butasagnak tartom azt, ami teljesen felesleges. Az alap fuggvenyeket, mint pl a memcpy, pedig feltetelezem mindenki ismeri, es nem szurja el (plane, ha az editor is van annyira intelligens, hogy eleve mutatja a parameterlistat).

> Nem akkor van gond, amikor írod, hanem amikor olvasod. Értem, hogy akkor is fölé lehet húzni az egeret, de jobban szeretem őket egyszerre látni.

En meg ugy vagyok vele, hogy ha valaminek nem tudom fejbol a szintaxisat, akkor szeretem latni. Egy egeret odahuzni kb semmibe nem kerul, es kapok egy szep tooltipet az adott fuggvenyrol.

> A példában idézett függvény az ARPACK függvénykönyvtárból van, és SZVSZ meglehetősen jó minőségű kód. A flexibilitás miatt van ennyi argumentuma, meg mert eredetileg FORTRAN.

Lehet, hogy jo minosegu kod, de nem szep. A tragya is lehet jo minosegu, de attol nem lesz szep. Az pedig, hogy eredetileg FORTRAN, szerintem nem mentseg. De izlesek es pofonok.

Nyilvan van olyan helyzet, amikor az ember nem egyertelmu koddal dolgozik, ilyenkor egy jo editor sokat segit, es nem kell megjobban elganyolni a kodot.

--
|8]

( tetra | 2011. 02. 10., cs – 10:08 )

Sok itt a C kernelhekker úgy érzem...
Amúgy én is mindig alkalmazkodom a meglévő kódhoz, de nem az volt a kérdés, hogy mit csinálsz, hanem hogy mit részesítesz előnyben, és akkor egyértelműen a 2.
----
Hülye pelikán

( utpKabel | 2011. 02. 10., cs – 10:09 )

Harmadik változat lényege, hogy bármely két sor közé beszúrhatsz egy új kódsort anélkül, hogy megborítanád a már meglévő kódok működését.

Mivel a diff-ek jellemzően soralapúak, így ebben a stílusban kevesebb fölösleges különbség látszik a patch-ekben, az egyes revíziók közötti diff-ekben, valamint kevesebb a hibalehetőség annak verziókezelő általi meghatározásában, hogy eredetileg ki committolt egy adott sort.

Na jo, mostmar ertem. De en erre nem gondoltam, mert ha valaki ilyen helyre szur be sort, a fordito ugyis visit. Tehat nincs futasideju hiba belole, ezert nem nagyon lenyeges kerdes.

Szerk:
Bocs, szelso esetben lehet belole futas ideju hiba, pl. a 2. stilus eseten. De azert ahhoz elegge erolkodni kell.

Mégis mi lenne? 


C:\work\hup>type e.php
<?php

$a = 0;
$b = 1;

if ($a == $b) {
    $a = 0;
}
$a = 5;
else {
    $b = 0;
}
C:\work\hup>php e.php
PHP Parse error:  syntax error, unexpected T_ELSE in C:\work\hup\e.php on line 1
0

Parse error: syntax error, unexpected T_ELSE in C:\work\hup\e.php on line 10

C:\work\hup>

De aki ennyire nem nézi meg azt, hogy hova ír ÉS még ráadásul le se teszteli, az vessen magára.

----------------
Lvl86 Troll

( nrgie | 2011. 02. 10., cs – 10:12 )

3.változat ha többsoros a művelet,

if {..}
else {..}

ha egy sorba belefér.

Szeretem a "zsúfolt" kódokat, mert gyorsan átlátom a lényeget.
Ergo, még a kommenteket is kiszedem ha megtehetem, mert nem azok alapján értelmezem a kódot, ezért számomra fölöslegesek és zavaróak úgy általában.

"Szeretem a "zsúfolt" kódokat", "még a kommenteket is kiszedem"
Egyszer kerülj közelebb egy ~800ezer sornyi kódot tartalmazó enterprise project bugfix feladataihoz, mindjárt nem fogod szeretni. ;)
--
"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

( levyt2005 v | 2011. 02. 10., cs – 10:20 )

Több ismerősöm is van, aki az alábbi technikát használja ( talán az egyik oktatónknál láttuk aki maga is programozó volt egy cégnél)

if ( féltétel )
{
utasitás1;
utasitás2;
}
else
{
utasitás3;
utasitás4;
};

Nem tévedés, a sorok közt egy üres sor van, így átláthatóbb a kód...

( uid_194 | 2011. 02. 10., cs – 10:35 )

Hianyzik az "Egyik sem, leirom" opcio.

Egyebkent reszemrol 2 & 3 all legkozelebb hozzam, amennyiben C-rol van szo. A 2. az GNU-style formaban: 


if ()
  {
    ...
  }
else
  {
    ...
  }

En ezt preferalom, de ez nincs a listan, bar a 2. kozel all. A 3. lenne a masodik helyezett, dehat amit elonyben reszesitek, az nincs a listan, igy nem tudok szavazni.

--
|8]

( xtonix | 2011. 02. 10., cs – 10:56 )

Nálunk nincs ilyen, hogy ki hogy szereti írni...
eclipse-hez van egy formázó, amit mindenki beállít, és ki kell pipálni, hogy mentésnél automatice formázzon...

a behuzas alapu kodstrukturalas valami ritka elmebeteg talalmany
nem keveset szoptunk ezzel anno pythonban (jo, ehhez az is kellett hogy par coder leszarja a policy es nekialljon space-ekkel indentalni TAB helyett, de mivel a nyelv sajnos megengedi, igy kivedhetetlen)
-
Slackware current / OSX Snow Leopard

( talisker | 2011. 02. 10., cs – 10:59 )

Megfontolandó egyébként, hogy egy sorba csak egy utasítás kerüljön. Még akkor is, ha azok olyan egyszerűek, mint pl.: i++;
Érdemes gondolni a későbbi debug-olhatóságra is.

Számtalanszor belefutottam anno olyan problémákba, amik az egy sorba összehányt kifejezéshegyek/utasítások hibás működéséből adódtak.
Jobb a békesség szerintem, ismerve egyes debuggerek lelkivilágát.

Bár ezek igen régi tapasztalatok, a mai up-to-date eszközökben lehet, hogy feleslegesek ezek az elővigyázatosságok.
Anno, amikor még nem volt kiforrott a C++ template kezelés megvalósítása egyes fordítókban, sokszor kézi makrózással helyettesítettük a dolgot, hogy a megfelelő működést elérjük.
Ebben az esetben qrvára számított, hogy ha a makrózótt kódot levetköztettük, az eredményül kapott forrásszöveg mennyire volt debugolható.

Tüzzel vassal irtottuk az egysorba írást.

Persze ez csak egy szempont.
---------------------------------------------------
Talisker Single Malt Scotch Whisky aged 10 years :)

( fdavid | 2011. 02. 10., cs – 10:59 )

A legjobban olvashato a 2. valtozat. Szepen kiemeli a blokkokat. A tobbi tul suru lesz.

( asch v | 2011. 02. 10., cs – 11:16 )

A négyest írtam, de meg tudom magyarázni. Az a lényeg, hogy az összetartozó zárójelpárok egymás felett legyenek, így könnyű követni, hogy mi hova tartozik. A 2. is jó, de az eggyel több sort használ.

Mellesleg egy tisztességes editorban, ami színez, illetve jelzi az összetartozó zárójeleket - simán tudok egysoros programot is írni.

Összetartozó zárójelnél erősen javasolt kommentekkel megjelölni az elejét - végét, pláne, ha nem fér ki egy képernyőre. Anno azt csináltuk, hogy pl. if esetén a feltétel (vagy egy része, ha hosszú volt) lett a záró } után kommentként megismételve. A cél az volt, hogy a záró zárójelről is ránézésre lehessen tudni, hogy mit zár le. (függvény esetén meg end _függvény_neve_ volt a komment)

( mrev | 2011. 02. 10., cs – 12:52 )

A 2. változatnak van egy objektív előnye:

Ha a kurzorral szigorúan függőlegesen pásztázom a kódot, akkor egy vezérlési struktúra minden összetartozó elemét megtalálom egymás alatt, így pl. könnyen tudom ellenőrizni. Szerintem ez a legfontosabb szempont, és ehhez fogható előnnyel semelyik másik stílus sem rendelkezik. (Elképzelhető persze, hogy valaki proporcionális fontot használ programozáshoz, de az mazochista.)

Vannak más kérdések is.

Mi van a tabokkal. Ugyebár, ha tabok és blankek vegyesen vannak a szövegben, akkor különböző editorokban másképp néz ki az indentálás, ráadásul el is mentődhet a fájl rossz indentálással. Egy python progam ilyenkor elromlik, brrr. Ezért egyáltalán nem használok tabokat.

Mekkora legyen az indentálás? Egytől (!) sokig mindent láttam már. Én 4-et használok.

Kell-e használni kapcsos zárójelt, ha csak egy sorra vonatkozik az if? Én használok.
--
CCC3

A szóközhasználat a logikus, az mindig egy karakter hosszú. A tabot én is száműzöm, de a vimes kollégák mégis telerakják néha a kódot tabbal :S
Én világéletemben a kettő szóközös indentálást használtam, és hálisten a cégnél is ez a policy. Pont elég, kétszer akkora, mint egy szóköz. Ha ennél nagyobb akkor nekem már nagyon töri a szöveget hogy messzire bemegy egy-egy indentálás.
Én sosem használtam kapcsost egysorosnál, de a cégnél az a policy, hogy kell, és megértem miért, de még szokni kell :)
----
Hülye pelikán

"Tabs are 8 characters, and thus indentations are also 8 characters.
There are heretic movements that try to make indentations 4 (or even 2!)
characters deep, and that is akin to trying to define the value of PI to
be 3."

Ha úgy érzed, hogy messzire bemegy egy indentálás, akkor az nem az indentálás hibája, hanem a kódodé.

Állj. A gyakorlatban bevált EGY HELYEN. EGY területen. Te meg azt állítottad az idézettel, hogy aki nem 8 karakteres behúzást használ az egy ... rossz ember. Szerintem meg ha látnál a saját seggeden túl is, akkor nem mondanál ilyen hülyeségeket. Példaként hoztam egy helyzetet, ahol kapásból 4. fokú indentálásnál tartasz, és még futó kódot nem írtál, csak deklarációkat.
----
Hülye pelikán

Egyszer talán a Microsoft megbízásából csináltak egy felmérést/kutatást, és kiderült, hogy a 4 karakteres indent a legoptimálisabb, ezért használ a Visual Studio ilyen megközelítést.

Egy előző munkahelyemen 2 karakteres "space" indentet használtunk. Nem mellesleg a space sokkal logikusabb is, mert minden rendszeren, minden szövegszerkesztőben megnyitva ugyanúgy néz ki. Azóta nekem vim telepítés/első indítás után is első dolgom, hogy beállítom a 2 karakteres space indentálást, mert bejött. :)
--
"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

( egmont | 2011. 02. 10., cs – 13:06 )

Egyértelműen a harmadik. Mindegyikhez hozzá lehet szokni, mindegyik természetesnek tűnik ha azt használod, és idegennek ha másikat. Viszont a harmadik az, amelyik nem pazarolja fölöslegesen a helyet, hanem egyszerre (azonos betűméret, azonos ablakméret, azonos monitor mellett) több kódot látok.

( emberk | 2011. 02. 10., cs – 13:10 )

A 2.-at azzal a megkötéssel, hogy az if helyett a feltétel alatt kezdem a "{" zárójelet. Nekem így jobban átlátható. Én így jobban átlátom. Mondjuk 5-6 egymásba ágyazott cilkusnál ezt fel szoktam rúgni (ez mondjuk ritka, mert ritkán nem megkerülhető). Mivel úgyis egyedül én kódolok C/C++-ban a cégben, így senkit nem zavar a helypocsékoló kódolásom.

------
3 fajta matematikus létezik. Aki tud számolni, és aki nem.

( Nickname | 2011. 02. 10., cs – 13:29 )

perverzióból:

final boolean expr = (...);

if (expr) {

}

if (!expr) {

}

( Mcsiv v | 2011. 02. 10., cs – 13:41 )

szintén egyéb, én pl ezt szoktam meg:

if ()
{
...
} else {
...
}

( bAndie9100 | 2011. 02. 10., cs – 14:05 )

3-t találom a leglogikusabbnak.
látom, a legtöbben szintén.
ilyen változtatással: 

if() {
 asd;
} else {
 qwe;
}

mint ahogy más függvényeknél is szorosan a függvénynév után kezdjük a zárójelet,
még akkor is ha egyes nyelvekben az if() nem függvény hanem nyelvi elem.

~~~~~~~~
De ezt az egy lépést ki nem tevé,
Az nem tett semmit, nem tud semmit is.

( bAndie9100 | 2011. 02. 10., cs – 14:05 )

3-t találom a leglogikusabbnak.
látom, a legtöbben szintén.
ilyen változtatással: 

if() {
 asd;
} else {
 qwe;
}

mint ahogy más függvényeknél is szorosan a függvénynév után kezdjük a zárójelet,
még akkor is ha egyes nyelvekben az if() nem függvény hanem nyelvi elem.

~~~~~~~~
De ezt az egy lépést ki nem tevé,
Az nem tett semmit, nem tud semmit is.

( bAndie9100 | 2011. 02. 10., cs – 14:09 )

3-t találom a leglogikusabbnak.
látom, a legtöbben szintén.
ilyen változtatással: 

if() {
 asd;
} else {
 qwe;
}

mint ahogy más függvényeknél is szorosan a függvénynév után kezdjük a zárójelet,
még akkor is ha egyes nyelvekben az if() nem függvény hanem nyelvi elem.

~~~~~~~~
De ezt az egy lépést ki nem tevé,
Az nem tett semmit, nem tud semmit is.

( freyr | 2011. 02. 10., cs – 14:59 )

A 2-est, behúzásokkal. Ezt szoktam meg, illetve egy hosszabb kód inkább átlátható, ha így épül fel, egyértelmű, hogy hol az adott blokk eleje és vége, a szerkezetből látszik, hogy mi hova tartozik, még mielőtt megnézné az ember magát a kódot.

( prkc v | 2011. 02. 10., cs – 15:11 )

A 4-est, nekem ez a legátláthatóbb.
(Nyilván ha egy projektben már vannak előre megadott szabályok akkor azok szerint.)

( meditor | 2011. 02. 10., cs – 15:52 )

if (){;}else{;}

(-::

> Sol omnibus lucet.

sőt:
() ? (function(){})() : (function(){})();
Nehogy már elhanyagoljuk a ternary operatort, amikor a sima elágazást mindenki felismeri… (a szomorú az, hogy rám amúgy tényleg jellemző a velük való visszaélés… De írásidőben gyakran nagyon kényelmes…)

int getRandomNumber() { // ←ez itt már az aláírásom
	return 4;//szabályos kockadobással választva.
}		//garantáltan véletlenszerű. xkcd

Sőt! rövidebb kód fordul rá! Én nagyon sokat használom.
Sokan beszélnek itt szellős kódról. Hát én úgy tömörítek, ahogy csak
lehet. Pl: egy ciklus, egy sor, ha nem hosszabb 90 karakternél.
Nagyon jó a tesztelésnél, ha ki kell iktatni a ciklust. Nagyon jó
áttekinteni a programot is.

A tömör kódolás legnagyobb előnye, hogy egyszerre nagyon nagy
kódrészlet van a képernyőn. Az öreg motorosok, akik már alig
debugolnak (kigyullad egy led vagy nem, azt slussz) tudják miről
beszélnek.

> Sol omnibus lucet.

Csak egy gombnyomás, ha kell. Tudod ugye? És, hogy mi az előnye,
ha egyszerre sok programsort tekintesz át, azt is tudod. Kár ezen
tornázni.

Sokkal fontosabb, hogy az _algoritmus_ követhető legyen. Majdnem
ugyanilyen fontos a helyes változónévválasztás (ez szinte felér
a jó kommentezéssel). Fontos továbbá a következetesség: ne válts
stílust és/vagy programozási szokásokat, elveket egy projecten
belül, vagyis légy következetés: rendkívüli módon megkönnyíti
a hibakeresést és az együttdolgozást.

Ezek mind-mind sokkal fontosabbak, mint az, hogy mit írsz egy sorba.
Ez az auto_formázók megjelenése óta gyakorlatilag mellékes. (Ha,
már a kódminőség szóba került.)

> Sol omnibus lucet.

( Kiskübi v | 2011. 02. 10., cs – 18:22 )

Mivel nem komálom azt, ha a nyitójelek az előző sor végén vannak, ezért 2-es vagy 4-es; de ha rövidebbre akarom fogni: 


if( feltétel )
{   utasítás;
    utasítás;
} else
{   utasítás;
    utasítás;
}

Régen ettől voltam rosszul; változik az ember. :-)

Néha direkt játszani szoktam vele, hogy ordenáré szar formázást használok, aztán nyomok egy entert, és kész is. Mit nem adtam volna ezért, amikor anno a progmatos házifeladatokban segítettem emberkéknek. :)
--
"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

( samu.ferenc | 2011. 02. 10., cs – 19:31 )

A 3.-ra szavaztam, de ha jobban belegondolok ez kicsit nyelv függő is.
C szintaktikájú nyelveknél a 3. viszont Delphi/Pascal-ban inkább a 4.

if () then
begin
end else
end;

A behúzást ti hogy csináljátok? Én két szóközt használok, pontosabban tabulátor, ami automatikusan cserélődik 2 szóközre.

( saxus | 2011. 02. 11., p – 05:26 )

2. Szeretem a szellős kódot.

Plusz továbbiak, amik szerintem ennél fontosabbak:
- Legyen szellős, jól olvasható a kód.
- Egy metódus/függvény lehetőleg ne legyen nagyobb, mint amennyi egy képernyőre kifér. (kb. 40-50 sor)
- Metódusok után minimum 2 sor legyen.
- Egy osztály lehetőleg egy fájl legyen.
- Minden dologról derüljön ki az, hogy mire való. Inkább legyen hosszabb neve, de egyértelmű és ne valami agyonrövidített cucc.
- Lehetőleg 80 karakternél ne legyen szélesebb egy sor, hogy jól olvasható legyen.
- SQL query szétbontva, indentálva, pl. 


$db->query('SELECT tamtaramtatam
    FROM akarhonnan
        LEFT JOIN megvalami USING (bigyula)
    WHERE ez AND az
    ORDER BY ingyombingyom
    LIMIT 10 OFFSET 0');

- Legyen kommentelve, ha valaki bugfixet csinál ott a helyén
- Mindig legyen zárójelezés. Sokkal egyértelműbb és hibamentesebb, ha mondjuk egy ilyet kell nézni ((a * b) + (c * d)), ahol egyből látszik az összetartozó tag.
- Legyen egységes a metóduselnevezés (meglepő, de csúnyán tudja lassítani az embert)
- Hungarian notation, bár ez még nem megy mindenhol tökéletesen... Nem olyan hülyeség az, főleg ha valami nem túl típusos nyelvben kell kódolni.
- Legyenek értelmes, debuggolható hibaüzenetek, logok, stb.
- Legyen SVN commit log és derüljön ki belőle, hogy mi a halált csinált. (hihetetlen, de egyeseknek ezt is magyarázni kell. Volt egy külsős arc, aki egy ideig nem írt, rászóltunk, aztán sokadjára elkezdett írni... Beírta mindig a nevét.
- Lehetőleg kisebb SVN commitok legyenek, amik egy részfeladathoz tartoznak, ne nap végén a n+sok megoldást egyszerre.
- Ha valami nyelvnek van értelmes és jól kidolgozott konvenciója (pl. C#), akkor azt kell használni.

----------------
Lvl86 Troll

"- Legyen SVN commit log és derüljön ki belőle, hogy mi a halált csinált."

Az, hogy mit csinált, úgyis kiderül a kódból. Szerintem sokkal érdekesebb, hogy _miért_ csinálta.

"- Lehetőleg kisebb SVN commitok legyenek, amik egy részfeladathoz tartoznak, ne nap végén a n+sok megoldást egyszerre."

Sajnos svn-ből pont hiányoznak azok az eszközök, amikkel ezt egyszerűen meg lehet tenni...

"Az, hogy mit csinált, úgyis kiderül a kódból."

Na persze. Aztán xezer commit közül meg akarsz nézni egyet, hogy egy adott delikvens mégis mit csinált vagy nem csinált.. Úgyvan.

"Sajnos svn-ből pont hiányoznak azok az eszközök, amikkel ezt egyszerűen meg lehet tenni..."

Nem az SVN-ből hiányoznak (SVN szerver benn van az irodában, olyan nincs, hogy nem elérhető és nem lehet commitolni, mert a világ másik felén van egy sivatag közepén és az egyetlen kommunikációs lehetőség az Iridium...), hanem hozzáállás kérdése. Ha valaki lusta és szarik rá, akkor nap végén egyben betolja a commit+push párost.

----------------
Lvl86 Troll

"Na persze. Aztán xezer commit közül meg akarsz nézni egyet, hogy egy adott delikvens mégis mit csinált vagy nem csinált.. Úgyvan."

A hangsúly azon lett volna, hogy a "mit" önmagában nem elég, a "miért" is van legalább olyan fontos. Példát lásd lejjebb.

"Nem az SVN-ből hiányoznak (...), hanem hozzáállás kérdése."

De, az SVN-ből hiányoznak. Ha egy file-ban két egymástól független változtatás van, akkor csak igen nyögvenyelősen lehet a két változást külön commitolni. Nincs se add --patch, se stash --keep-index, se interaktív rebase, amikkel összehasonlíthatatlanul könnyebb logikai egységenként tagolt commitokat létrehozni. Igen, a hozzáállás is számít, de hiába van nekem megfelelő hozzáállásom, ha a verziókezelő nem nyújt ehhez támogatást, akkor csak sokkal nehezebben és lassabban tudom ezt megcsinálni. Van nekem elég dolgom anélkül is, hogy a verziókezelő hiányosságaival küzdjek.

A szerver hollétének ehhez semmi köze nincs.

Igen, a hozzáállás is számít, de hiába van nekem megfelelő hozzáállásom, ha a verziókezelő nem nyújt ehhez támogatást, akkor csak sokkal nehezebben és lassabban tudom ezt megcsinálni. Van nekem elég dolgom anélkül is, hogy a verziókezelő hiányosságaival küzdjek.

Ez egy nagyon fontos dolog. A verziókezelő rendszernek segítenie kell a munkában, nem hátráltatnia abban.

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

"Ha egy file-ban két egymástól független változtatás van, akkor csak igen nyögvenyelősen lehet a két változást külön commitolni. "

Mondjuk ez elég ritka felénk, de mi ad erre rendes megoldást?

De gondolom abban azért kiegyezhetünk, hogy az gáz, ha valaki a nevét írja be commit logba és nap végén egyszer commitol...

----------------
Lvl86 Troll

> Mondjuk ez elég ritka felénk, de mi ad erre rendes megoldást?

Nalam ez rettento gyakori. Foleg amikor egy ujabb fejlesztest integralok be mashova, es kozben derul feny az uj fejlesztes hianyossagaira. Ilyenkor kijavitom a hibat, de azt nyilvan nem az integralassal egyutt akarom commitolni, mert ket teljesen fuggetlen dolog.

git add -i tokeletes megoldas erre a problemara.

> De gondolom abban azért kiegyezhetünk, hogy az gáz, ha valaki a nevét írja be commit logba és nap végén egyszer commitol...

Hat attol fugg. Ha az AUTHORS fileba irta bele magat, es mast nem csinalt aznap, akkor ez teljesen korrekt commit log :D

--
|8]

( Lacaa v | 2011. 02. 11., p – 09:15 )

4-est jelöltem, a 2-est is jelölhettem volna.
A helytakarékosság egyre kevésbé szempont, ahogy nő a képernyők felbontása.
Egy } nem egy if-fel, while-lal stb. tartozik egybe, hanem a {-el, az istenitneki.
Ezért ezeknek kell egy oszlopban lenniük (vagy egy sorban, ha elég rövid az a sor, és elég távol van a legközelebbi másmilyen struktúra).
Az összes többi ügyben velem lehet beszélni.