indentations - NEM hitvitát kérnék ..

"ANSI van, kivéve a ciklusokat, feltételeket stb.. hát elnézést a kifejezésért de ez így elég hányadék, keverve.."

ezt nem ertem

maskulonben hasznos lehet a KNF-et megtanulni, az elegge pontosan meghatarozott, esztetikus es elegge elterjedt (Solaris, BSD)

ui.: hardtab rulz

--
When in doubt, use brute force.

Probald ki es ahogy jobban atlatod a kodot. Aztan majd a melohelyeden az ott megszokott/eloirt rendszert kell kovetned...

Nekem csak haml miatt fontos a 2 space = 1 tab beállítás a szerkesztőben. Bár akkor már lehetne 1 space is, nem is értem mire jó a 2-vel való oszthatóság, ha sehol nem használjuk ki a páratlan space behúzású sorok hordozta többletinfót.
Amit kényelmesebb átlátni, az a jó.

http://hackles.org/cgi-bin/archives.pl?request=98
:D
---------------------------------------------
"Az aptitude-nak nincs Szuper Tehén Ereje" :D

Én a {}-t mindig külön sorba kezdem (Java és C/C++-ban), mert így egymás fölé kerül a nyitás és a zárás, jól látszik mi tartozik össze.
Csak tabot használok (Java, C, Python), így akár menet közben is átállíthatom mennyi az annyi és nem kell izomból nyomogatni a space-t. Az editorom támogatja több sor egyszerre ki-be tolását, úgyhogy az is gyorsan megy.
switch esetén a case-eket is beljebb kezdem így:

switch (cica)
{
 case fekete:
  print ("Gyere, fekete cica!");
  break;
 case vörös:
  print ("Gyere, vörös cica!");
  break;
}

Nem mintha bárkit érdekelne, csak az ilyen hülyeségekre muszáj írnom :-).

En a klasszikus Java indentation-t hasznalom C/C++/Java nyelvekhez, meghozza ugy, hogy a space-k ki vannak bontva 4 darab space-ra. A fejlesztokornyezetek tobbsegeben beallithato feature az, hogy az indentalo space-ket egy csomoban lehessen backspace-lni, amelyikben nem, azt surgosen dobni kell. Nehany IDE ezt ugyan nem a standard backspace-hez kotik, hanem van kulon unindent kombo, de meg ez is szokhato.

Nem szeretem a {} -t semmilyen korulmenyek kozt uj sorba tenni, mert nem olyan feltuno, mint peldaul sor vegen. Ugyanakkor a legtobb IDE tamogatja a zarojelpar-keresest, amelyik nem, az ismetelten a szemetdombra valo.
Tabot en azert nem szeretem, mert sok editor mast es mast ert Tab alatt - pontosabban annak szelessege alatt. En peldaul a 4-es szelessegu indentalast kedvelem Java, C/C++, Python, Bash nyelveknel, 2 szelessegut hasznalok a Ruby nyelvben. Ez space-kkel egyszeruen szabalyozhato, es nem kell felkilometeres editor-vezerlo kommentet irni minden fajl vegere, hogy minden editor azt es ugy ertse indentalas alatt, amit en.

Altalaba astyle-val szoktam ujraindentalni, a kovetkezo konfiggal (.astylerc):

style=java
indent-classes
indent-namespaces
pad=oper
unpad=paren

Ez tukrozi a leghivebben a kodolasi stilusomat.
--

()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Mindenki maskepp csinalja, ez ne zavarjon! Hasznald azt, ami neked a legjobban tetszik, majd amikor egy komoly csapatnak a tagja leszel, ott ugyis lesz egy egyseges coding style, amit kovetni kell...

----------------------
"ONE OF THESE DAYS I'M GOING TO CUT YOU INTO LITTLE PIECES!!!$E$%#$#%^*^"

"Tudom hogy tab-ra beállíthatok X db. space-t, de ilyenkor a kód javításához kell egy valag space/tab."

Egyes szövegszerkesztők tudnak olyat (pl. Vim), hogy a backspace-nél úgy törli a space-t, mintha tab lenne (pl. 4-essével). Python-nál ezt használom. És tud több sor indentálását egyszerre változtatni.

Nem akarlak rábeszélni semmire, hallgass a többiekre :)

Én ha C/C++ kódot követek el, ezeket veszem alapnak:
C kódolási szabvány és CPP kódolási szabvány -- (A svéd ELLEMTEL Telecommunication Systems Laboratories angol nyelvű anyagainak a fordításairól van szó.)

"- Érdemes-e áttérnem a külön-sorba-a-kapcsos-zárójel módszerre C++ esetében.
- Miért használ valaki/bárki/akárki space-t tab helyett? Miért kezd ez "szabványosodni"?"

Szerintem mindkét kérdésre a válasz: teljesen mindegy, ki mit használ, a lényeg, hogy cégen, projekten belül egységes legyen. Nem az a lényeg, hogy szép a kód, meg olvasható, hanem hogy van egyáltalán kódolási szabvány, hogy megkönnyítse a kódok olvasását, az egyes fejlesztők együttműködését.

Azért érdemes külön sorba, egymás alá írni a {} jeleket, mert amikor keresed az összetartozó párokat tudod, hogy pontosan egymás alatt vannak. Akkor is, ha esetleg 200 sorral lejjebb vagy feljebb kell keresni.

    if(  )
    {
        ...
    }

Azért érdemes tab helyett spacekat használni, mert akkor (1) a szöveg megjelenése nem függ attól, hogy az editorod hogyan értelmezi a tabokat. Másrészt (2) én úgy szoktam törölni, hogy lenyomva _tartom_ a del vagy a backspace billentyűt. Ha tabok is vannak a whitespacek között, akkor hirtelen begyorsul a törlés, és beletörlök olyanba is, amibe nem akartam.

Pythonban a tabok összezagyválódása katasztrófális.

Rossznak tartom, ha egy program megkülönbözteti a spacet és a tabot, ahogy a make teszi.
--
CCC3

Ha valami nagyobb dolgot csinálok, akkor netbeanst használok, ha tényleg egy fájlos a történet (valami proof-of-concept kód, vagy egy projekt egyetlen egy fájljába kell csak belepiszkálni), akkor vim. Mindkettő jól finomhangolható.
Drupal esetén szigorúan követem az ottani kódolási konvenciót (nagyrészt ugyanaz, mint a GNU), egyéb projektekben annyi különbséget teszek, hogy a 2 space helyett egy tabot használok (nem bontom ki space-ekre).

Egy függvény kb így néz ki nálam (Drupal kódolási konvenció, 2 space tab helyett):

function foo(array $param0, MyClass $param1, $param3 = NULL) {
  $var = 0;
  for($i = 0; $i < $param3; ++$i) {
    if($param1->foobar($i))
      $param1->doFoobar();
  }
  foreach($param0 as $p) {
    $param1->setVal($p);
    ++$var;
  }
  return $var;
}

Konvenciók, amik nem tetszenek:

function foo()
{
  ...
}

  function bar()
  {
...
  }

Nem tetszik, ha a { új sorban van, mert nem esztétikus :)
Nagy kód esetén nálam sokkal többet segít, hogy a kultúráltabb editorok megjelölik a másik felét, minthogy egy oszlopban van.

man style

STYLE(9) FreeBSD Kernel Developer's Manual STYLE(9)

NAME
style -- kernel source file style guide

DESCRIPTION
This file specifies the preferred style for kernel source files in the
FreeBSD source tree. It is also a guide for the preferred userland code
style. Many of the style rules are implicit in the examples. Be careful
to check the examples before assuming that style is silent on an issue.

....

and so on

--
.