Übersicht: Einrückungsarten

Welche Variante nutzt Ihr ?

  • Variante 1

    Abstimmungen: 29 52,7%
  • Variante 2

    Abstimmungen: 29 52,7%
  • Variante 3

    Abstimmungen: 1 1,8%

  • Anzahl der Umfrageteilnehmer
    55
#1
Mal eine etwas andere Umfrage.
Ich möchte mal von euch Wissen welche Einrückungsart Ihr nutzt.

Code:
[B]Variante (1)[/B]

Die öffnende Klammer steht direkt hinter der Bedingung und die schließende Klammer bündig mit dem if, um den Anweisungsblock zu schließen:
[COLOR="Navy"]if (Ausdruck){
    Anweisungen
}[/COLOR]
  
[B]Variante (2)[/B]

Beide Klammern werden bündig mit dem if ausgerichtet und die Anweisungen werden eingerückt:
[COLOR="navy"]if (Ausdruck)
{
    Anweisungen
}[/COLOR]
 
[B]Variante (3)[/B]

Sowohl die Klammern als auch die Anweisungen werden eingerückt:
[COLOR="navy"]if (Ausdruck)
    {
    Anweisungen
    }[/COLOR]
Ich nutze die Variante 2.
 
Zuletzt bearbeitet:
#3
Variante 2 ist die übersichtlichste :thumb_up:
Das ist wohl eher Geschmackssache. Da ich mit Variante 2 die Funktionen einleite, könnte ich mit Variante 2 bei Bedingungen nicht mehr zwischen Funktionsanfang und Bedingung unterscheiden. Daher nutze ich für Bedingungen und Schleifen Variante 1.

Daher:

Code:
returntyp funktionsname(parameter)
{
  bedingung/schleife {
    ...
  }
}
 

Brabax

New member
#4
Code:
Variante (4)

Sowohl die Klammern als auch die Anweisungen werden eingerückt:
if (Ausdruck)
    {
        Anweisungen

        #Kommentar
            Anweisungen

        Schleife()
            {
                Anweisung
            }
    }
Habe ich mir bei HTML so angewöhnt und behalte es nun bei, weil ich so öffnende und schließende Klammern [-->bei HTML die Tags] sehr schnell einander zuordnen kann.

Klar hat man dadurch sehr weite Einrückungen, aber auch in langen Codesegmenten behält man noch sehr gut die Übersicht.

Zusätzlich mache ich gerne Einrückungen in Logik-Abschnitten, wie mit dem Kommentar angedeutet.
 
#5
Hab mir schon vor längerem Variante 1 angewöhnt. Ist auch hilfreich wenn es keine Klammern gibt (z.b. bash-sript)

Code:
while [ TRUE ]
do[INDENT]echo Hallo
sleep 10[/INDENT]done
 
#6
Schon interessant Variante 1 und 2 werden nahezu gleich oft genutzt, während Variante 3 bisher gar nicht vertreten ist. Hätte ich persönlich nicht gedacht.
 
#7
Ich halte es auch mit Variante 2.

Ich sehe das wie odigo: Das ist einfach die übersichtlichste Methode...;)

Ehrlich gesagt habe ich mich schon immer gewundert, warum man in der Fachliteratur meist Variante 1 bevorzugt.
 

benediktibk

Standardgruppe für nicht aktivierte User
#9
Variante 1 ist übles Java-Satans-Werk ... :D
Ich bevorzuge Nr. 2, ist in meinen Augen die übersichtlichste. Ein Problem mit zu vielen Einrückungen kann eigentlich nie entstehen, weil sobald eine Funktion eine Verschachtelungstiefe größer als 2 hat sollte man sie sowieso zerschlagen.

mfg benediktibk
 
#10
Ich sehe ehrlich gesagt keinen Unterschied in der Übersichtlichkeit bei den drei Varianten.
Ich verwende Variante 1 einfach weil ich mir eine Zeile spare und ich denke, das ist auch der Grund, warum diese Variante auch in Fachliteratur bevorzugt wird. Oft sind mehr als 1000 Zeilen Code in solchen Büchern und dann macht das was aus.
 
#11
Also wenn ich einen erwische der Variante 3 oder 4 benutzt würde ich ihn nicht den Kopf abreißen sondern glauben das sein Texteditor oder Mergetool einen Bug hat. Ich handhabe es so wie bitmuncher es beschrieben hat also eine Kombination aus 1 und 2. So sieht auch der meiste professionelle Code aus.
 
#12
Ich nutze die, die von der IDE vorgegeben / unterstützt wird.

Sprich, bei Java (Eclipse) Variante 1.

Bei C# (Visual Studio) Variante 2.


Variante 3 habe ich früher bei PHP ohne IDE verwendet.
 
#14
Ich nutze die, die von der IDE vorgegeben / unterstützt wird.
Eigentlich erwarte ich mir von der IDE ja das sie sich nach mir richtet, und nicht umgekehrt. ;) Aber das lässt sich ja in Eclipse wie auch in Visual Studio ändern.

Ich bevorzuge Variante 1, da spar ich mir haufenweise Zeilen. Übersichtlich wirds durch Leerzeilen und/oder Kommentaren vor der Klasse bzw. Funktion.
 
#15
Anfangs mit Variante 2 aber mittlerweile ( lag wohl an Eclipse ) auf Variante 1 umgestiegen. Die Kombination von bitmuncher finde ich ziemlich gut, das macht es übersichtlicher :wink:
 

bluez

Member of Honour
#16
Code:
Variante (4)

Sowohl die Klammern als auch die Anweisungen werden eingerückt:
if (Ausdruck)
    {
        Anweisungen

        #Kommentar
            Anweisungen

        Schleife()
            {
                Anweisung
            }
    }
[...] weil ich so öffnende und schließende Klammern [-->bei HTML die Tags] sehr schnell einander zuordnen kann.

Klar hat man dadurch sehr weite Einrückungen, aber auch in langen Codesegmenten behält man noch sehr gut die Übersicht.
mache ich genauso, mit denselben Begründungen.
Die Variante fehlt echt in deiner Umfrage :p

EDIT: Damit hätte diese Variante sogar schon zwei Stimmen mehr als Variante 3 :p
 
L

Lrsklpn

Guest
#17
Ich benutze die Variante 1 aus dem einfachen Grund, dass mein Eclipse es so formatiert und ich zu faul bin es umzustellen :)
 
#18
Ich komme nicht umhin zu bemerken, dass viele User sich von Eclipse tyranisieren lassen - daher werde ich mein diesbezügliches Tutorial in naher Zukunft um einen Absatz erweitern, der genau erklärt wie einfach und nahezu problemlos sich derlei Format-Probleme unter Eclipse beheben lassen(obwohl odigo eigentlich bereits alle nötigen Schritte genannt hat)...;)

Edit:
Thunder11 hat gesagt.:
Ich verwende Variante 1 einfach weil ich mir eine Zeile spare und ich denke, das ist auch der Grund, warum diese Variante auch in Fachliteratur bevorzugt wird. Oft sind mehr als 1000 Zeilen Code in solchen Büchern und dann macht das was aus.
Das ist übrigens eine sehr schlüssige Argumentation, die mich vollends überzeugt hat - also in der Frage warum Fachbücher diese Notation verwenden.
 
Zuletzt bearbeitet:
#19
Ich spüre da etwas zu viel Sarkasmus in einem Satz. Ich versuche mich anders auszudrücken:
Wenn man - wie ich - davon ausgeht, dass sich durch Notation 1 die Lesbarkeit des Codes nicht verschlechtert ist sie meiner Meinung nach zu bevorzugen: Wenn ich Verleger wäre, würde ich - was neue Programmierbücher angeht -, eher die Drucken lassen, die kürzer sind (die anderen wären unter obiger Annahme ja grundlos länger!) und sich zu akzeptableren Preisen verkaufen lassen.
Natürlich ist die genannte obige Annahme nicht irgendwie belegbar, es ist nur eine subjektive Meinung, aber solange es auch meine Meinung ist, müsste meine Argumentation zumindest in Ordnung sein.
Es ist ja auch nicht das unsinnigste von der Welt, dass man als Verleger oder allgemein als Unternehmen aus so wenig wie möglich, so viel wie möglich an Gewinn ziehen will.

mfg Christian
 
Oben