Umfrage: Welchen Indent style verwendet ihr

DEvent

Indent Style schrieb:

Dennoch muß ich sagen, daß ich if Blöcke grundsätzlich in geschweifte Klammern setze, auch dann, wenn wenn sie nur einen Ausdruck haben.

Z.B. so:
if (true)
{
  machwas();
}
else
{
  if (true)
  {
    machmehr();
  }
  else
  { 
    machnixmehr();
  }
}
Das verhindert, daß der Compiler bei den IF Blöcken Ratespielchen spielt, welcher denn nun jetzt Vorrang hat.

Vorbildlich
Ich verwende auch den

Allman style

und ebenso wie Indent Style bei allen If, While und For die {} setzen, allerding weniger wegen dem Compiler. Wenn der Compiler wegen sowas durcheinander kommt, dann sollte man diesen wegschmeisen. Es ist eher fuer den Lesen, damit er nicht durcheinander kommt.

DEvent schrieb:

Wenn der Compiler wegen sowas durcheinander kommt, dann sollte man diesen wegschmeisen.

ausser bei sprachen, bei denen einrückung strukturelement ist, kannst du auch alles in eine zeile schreiben. das 'nem compiler ziemlich egal.

Indent Style schrieb:

Aber in Zweiten von hohen Auflösungen und Widescreen habe ich da sehr viel Platz.

max. 80 zeichen pro zeile sind scheints aus der mode

alter hase schrieb:

Indent Style schrieb:

Aber in Zweiten von hohen Auflösungen und Widescreen habe ich da sehr viel Platz.

max. 80 zeichen pro zeile sind scheints aus der mode

Ja, zumindest bei mir.

80 Zeichen sind halt schon wenig und einen direkten Nutzen hat man nicht davon wenn man sich daran hält.
Niemand mehr programmiert direkt in der Konsole und die, die es z.b. unter Linux dennoch tun, die nutzen dann hoffentlich auch den VESA Framebuffer und der kann in höheren Grafikmodi auch mehr als 80 Zeichen pro Zeile darstellen.

Außerdem, Platz in der breite hat man bei modernen Widescreen Monitoren genug.
Aber der Platz in der Höhe ist schon stark eingeschränkt und gerade der sorgt ja für den größeren Überblick.

Daher macht es Sinn, wenn man die Breite für Parameter möglichst ausnutzt
und nicht alles untereinanderstellt nur weil man die 80 Zeichenlänge einhalten will.

DEvent

Indent Style schrieb:

alter hase schrieb:

Indent Style schrieb:

Aber in Zweiten von hohen Auflösungen und Widescreen habe ich da sehr viel Platz.

max. 80 zeichen pro zeile sind scheints aus der mode

Ja, zumindest bei mir.

80 Zeichen sind halt schon wenig und einen direkten Nutzen hat man nicht davon wenn man sich daran hält.
Niemand mehr programmiert direkt in der Konsole und die, die es z.b. unter Linux dennoch tun, die nutzen dann hoffentlich auch den VESA Framebuffer und der kann in höheren Grafikmodi auch mehr als 80 Zeichen pro Zeile darstellen.

Da muss ich entschieden widersprechen. Zum einen hat nicht jeder einen breiten Monitor, zum anderen haben moderne IDEs links und rechts Fenster (fuer Typenuebersicht, Klassenuebersicht, usw, siehe Eclipse) und zum dritten fuehrt die Regel der 80 Zeichen dazu, dass Verschachtelungen flach gehalten werden (also das nicht mehr als 3 oder 4 If-Verschachtelungen benutzt werden).

find halt vertikales scrollen besser als horizontales. ich hab kein widescreen, aber zwei monitore. das gute an files, die nur 80 zeichen haben, man kann neben dem editor noch nen file browser und ne konsole offen haben, oder sonst was. nach unten scrollen muss man eh ab ner gewissen zeilen zahl.

audacia

alter hase schrieb:

find halt vertikales scrollen besser als horizontales. ich hab kein widescreen, aber zwei monitore. das gute an files, die nur 80 zeichen haben, man kann neben dem editor noch nen file browser und ne konsole offen haben, oder sonst was. nach unten scrollen muss man eh ab ner gewissen zeilen zahl.

Das sehe ich ähnlich. Nur weil man einen Breitbildmonitor hat, muß man nicht geltende und sinnvolle Standards brechen und ihn in voller Breite mit Codezeilen füllen. Oder schreibt ihr neuerdings eure Diplomarbeiten auch im Breitbildformat?
Zudem ist auch die Codedichte in diesem Falle geringer, da nur verhältnismäßig wenige Zeilen länger als 80 Zeichen werden; das drosselt die Lesegeschwindigkeit gewöhnlich etwas.

(Allerdings muß ich fairerweise anfügen, daß es gerade in C++ schwerfällt, 80 Zeichen einzuhalten. Zuweilen wäre die Anhebung auf 100 ganz förderlich, da einfach allzuoft Zeilen wie
for (std::map <KeyT, ValueT>::const_iterator i = theMap.begin (), e = map.end; i != e; ++i) auftauchen.)

Dravere

audacia schrieb:

(Allerdings muß ich fairerweise anfügen, daß es gerade in C++ schwerfällt, 80 Zeichen einzuhalten. Zuweilen wäre die Anhebung auf 100 ganz förderlich, da einfach allzuoft Zeilen wie
for (std::map <KeyT, ValueT>::const_iterator i = theMap.begin (), e = map.end; i != e; ++i) auftauchen.)

Ich probiere auch immer die 80 einzuhalten, habe aber ein Maximum von 120 eingestellt, wo es mir dann eine gestrichelte Linie hinzeichnet (danke VAX).

Allerdings so eine Zeile würde ich auseinander nehmen:

typedef std::map<KeyT, ValueT> TheMap;

// ...

typename TheMap::const_iterator iter = theMap.begin();
typename TheMap::const_iterator end = theMap.end();

for(; iter != end; ++iter)
{
   // ...
}

@C-Chinesisch,
Man kann es auch übertreiben
Es gibt einfach Fälle, wo es besser erscheint. Zum Beispiel auch bei der Defintion von Konstanten, mag ich das sehr:

class Foo
{
public:
  static int const CONSTANT_ZERO    = 0;
  static int const CONSTANT_ONE     = 1;
  static int const CONSTANT_TWO     = 2;
  static int const CONSTANT_THREE   = 3;
  static int const CONSTANT_FOUR    = 4;
  // ...
  static int const CONSTANT_EIGHT   = 8;
  // ...
};

(so sinnfrei das Beispiel nun auch ist)

@asc,
Noch ein gutes Argument, muss mir das mal anschauen, ob ich das nicht auch anders mache.

Grüssli

audacia schrieb:

(Allerdings muß ich fairerweise anfügen, daß es gerade in C++ schwerfällt, 80 Zeichen einzuhalten...

mach dir doch nen haufen #defines, typedefs und geh' in die namespaces rein. damit kann man vieles abkürzen. jedes mal std::blah::blupp::pups hinzuschreiben, ist doch wirklich doof.

abc.w

@C-Chinesisch,
Man kann es auch übertreiben
Es gibt einfach Fälle, wo es besser erscheint.

Ja ok, ich habs ja auch ein wenig übertrieben dargestellt, um Leute herauszufordern, die so was gerne eintippen. Bin inzwischen "abgehärtet" und rege mich nicht mehr so auf (solange nicht ich den Code debuggen muss.. hehe). Und inzwischen ist mir auch egal, in welchem Still ich den Code formatieren soll.
Was mir aber persönlich wichtig ist, dass man die Möglichkeit hat und wenn es sein muss, an möglichst vielen Stellen im Code einen Breakpoint setzen zu können. Und mit diesem Gedanken im Hinterkopf schreibe und formatiere ich den Code (versuche es zumindest...). Zum Beispiel, was nützt mir der folgende Code im Debugger:

return a -= (0 != b) c: d;
// oder so
if (0 != b) return a -= c; else return a -= d;

Klar, kann man in den Zeilen einen Breakpoint setzen, aber kann man denn sicher daraus sehen, was wirklich zurückgegeben wird? Man kann sich im Debugger die lokalen Variablen angucken und mit Windows-Taschenrechner nachrechnen. Oder man kann bis in die Assembler-Ebene durchsteppen und sich dort das Ergebnis angucken... Aber wäre es von Anfang an nicht besser, gleich so hinzuschreiben, dass man im Debugger beim Durchsteppen auch gleich das Zwischenergebnis sieht (wozu auch immer, aber vielleicht gibt es dadurch einen Hinweis mehr, wo der Fehler im Code liegen könnte):

if (0 != b)
{
    a -= c;
}
else
{
    a -= d;
}
return a;

Hoffe, ihr versteht, was ich meine...

Hallo

Zum Debuggen schreibe ich so etwas auch gerne um, aber zum Lesen, finde ich knackig wirklich besser.

chrische

if (foo != 42)
{
    bar;
}

kann man natürlich machen, man darf dann nur nicht einen dummen Fehler machen, wie es mir mal passiert ist:

if (foo != 42)
//  foo ist nicht 42
{
    bar;
}

nach mühsamer Fehlersuche an allen möglichen Stellen stellte sich heraus, daß das Compilat im Fall (foo==42) lediglich die Kommentarzeile übersprang, sodaß bar in jedem Fall ausgeführt wurde.

Christoph

u_ser-l schrieb:

kann man natürlich machen, man darf dann nur nicht einen dummen Fehler machen, wie es mir mal passiert ist:
if (foo != 42)
//  foo ist nicht 42
{
    bar;
}
nach mühsamer Fehlersuche an allen möglichen Stellen stellte sich heraus, daß das Compilat im Fall (foo==42) lediglich die Kommentarzeile übersprang, sodaß bar in jedem Fall ausgeführt wurde.

Das würde ich nochmal kompilieren und testen. Denn ganz so schlimm ist C++ dann doch wieder nicht.

leider doch. Ich hatte das Problem an einer solchen Stelle auch überhaupt nicht erwartet und deshalb zunächst an allen anderen Stellen gesucht, nur nicht dort Ist allerdings inzwischen 9 Jahre her.

audacia

Den Compiler will ich gar nicht kennen

DEvent schrieb:

Da muss ich entschieden widersprechen. Zum einen hat nicht jeder einen breiten Monitor, zum anderen haben moderne IDEs links und rechts Fenster (fuer Typenuebersicht, Klassenuebersicht, usw, siehe Eclipse)

Ja, aber der Platz ist dennoch groß genug um mehr als 80 Zeichen auf den Bildschirm bringen zu können.
Trotz Eclipse!

und zum dritten fuehrt die Regel der 80 Zeichen dazu, dass Verschachtelungen flach gehalten werden (also das nicht mehr als 3 oder 4 If-Verschachtelungen benutzt werden).

Und das sehe ich wiederum als Nachteil wenn man nur 3-4 If Verschachtelungen nutzt, aber mehr sinnvoll wären.

Denn gerade mit guten tief verzweigten If-Verschachtelungen kann man viel Rechenpower einsparen und wenn das ganze in einer Schleife läuft, zählt das umso mehr.

audacia schrieb:

Das sehe ich ähnlich. Nur weil man einen Breitbildmonitor hat, muß man nicht geltende und sinnvolle Standards brechen und ihn in voller Breite mit Codezeilen füllen. Oder schreibt ihr neuerdings eure Diplomarbeiten auch im Breitbildformat?
Zudem ist auch die Codedichte in diesem Falle geringer, da nur verhältnismäßig wenige Zeilen länger als 80 Zeichen werden; das drosselt die Lesegeschwindigkeit gewöhnlich etwas.

Nur weil ich mehr als 80 Zeichen nutze, bedeutet das noch lange nicht,
daß ich mehrere Anweisungen in eine Zeile packe.
Genau das tue ich nämlich nicht.

Aber ich spare mir Umbruche bei Funktionsnamen & Parametern usw.

audacia

Indent Style schrieb:

Nur weil ich mehr als 80 Zeichen nutze, bedeutet das noch lange nicht,
daß ich mehrere Anweisungen in eine Zeile packe.
Genau das tue ich nämlich nicht.

Nicht, daß ich das behauptet hätte.

abc.w

Es gibt in der Dokumentation des Linux-Kernels (/usr/src/linux/Documentation) eine Datei CodingStyle. Interessant zu lesen, was da so alles steht. Gleich in Chapter 1: Indentation

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.

Und dann noch so was:

Now, some people will claim that having 8-character indentations makes the code move too far to the right, and makes it hard to read on a 80-character terminal screen. The answer to that is that if you need more than 3 levels of indentation, you're screwed anyway, and should fix your program.

Interessante Einstellung...