Wie formatiert ihr euren Code?

Hi

Als ich grad im Forum nach interresanten Snippets gesucht habe ist mir aufgefallen das ich meinen Code (solange ich ihn nicht hier poste) anders formatiere als ich würd mal sagen 60% der Leute hier.

Deswegen wollte ich mal fragen, wie formatiert ihr euren Code?

Also ich bin da ziemlich Platzsparend:

//z.B. Anstatt dem:
foreach (Control c in this.Controls)
{
if(c.Controls.Count > 0)
{
MessageBox.Show("asdf jklö";);
}
}

//Würde ich einfach das schreiben:

foreach (Control c in this.Controls) if(c.Controls.Count > 0) MessageBox("asdf jklö";);


//Was ich auch hasse ist wenn man die geschwungene Klammer bei einer Schleife oder so ähnlich nicht in einer neuen Zeile macht:

if(a == b) {
MessageBox.Show("Das hasse ich abgrundtief keine Ahnung wieso xD?";);
}

//Bei if-Statements mach ich immer geschwungene Klammern wenn es mehrzeilig ist bei Switch - Case Statements mach ich nie geschwungene Klammern egal ob mehrzeilig oder nicht ;)

Switch(a)
{
case "a":
a = "b";
b = "a";
case "b":
a = "a";
b = "b";
}

Habt ihr da auch solche "Eigenheiten" wie ich 👅 ?

Ich benutze Regions.

Ich programmiere platzverbrauchend. Also wie die 60 %. Und wie die Standardformatierung von Visual Studio einrückt.
Regions verwende ich auch.

grüße
webstarg

Das Platzverbrauchend kommt bei mir drauf, je wie Visual Studio eingestellt ist. Zuhaus geschweifte Klammer auf, aktuelle Zeile. Arbeit kommt das in eine neue Zeile. Grund, die Kollegen (einige) können das nicht lesen, wenn die Klammer in der selben Zeile steht wie das if, while usw.

Einzeilige Anweisung verwende ich auch, allerdings versuche ich maximal das ganze auf 2 Anweisungen/Abfragen zu begrenzen

foreach (Control c in this.Controls) 
  if(c.Controls.Count > 0) MessageBox("asdf jklö");

Switches werden wie folgt geschrieben:

Switch(a){
  case "a":
    a = "b";
    b = "a";
    break;//a
  case "b":
    a = "a";
    b = "b";
    break;//b
}

resharper-standard einstellung.

geschweifte klammern immer in eine neue zeile. ansonsten ist der rest soweit ich weiß wie in vs05.

Ich programmiere eher platzverbrauchend. Ist imho leserlicher. Für mich wichtig: geöffnete Klammer in die nächste Zeile, sonst sieht das so asymetrisch aus.

foreach (Control c in this.Controls)
{
    if(c.Controls.Count > 0)
    {
        MessageBox("asdf jklö");
    }
}

ich finde es übersichtlicher wenn man es so schreibt:

if(a == b) MessageBox.Show("a";);
else MessageBox.Show("b";);

Aber ich akzeptiere eigentlich alles so lang es symetrisch ist deswegen mag ich auch nicht die schreibweise wo die erste geschwungene Klammer in der gleichen Zeile wie das if ist.

...können das nicht lesen, wenn die Klammer in der selben Zeile steht...

Das muss ich in der Berufsschule so ertragen und muss mich auch daran halten (C++).
Ich verstehe nicht wie das eine feste Vorgabe sein kann. So kann man den Code überhaupt nicht lesen (meine Meinung).

Deswegen programmier ich auch platzverbrauchend. Lässt sich besser als jedes Buch lesen..
Ausnahmen sind kleine Anweisungen, bei denen man echt ein bisschen Platz ohne Probleme sparen kann, jedoch wenn sich die Anweisung "klein" hält.

Beispiel:

if (count = 0) return false;
// hier geht der code weiter falls bedingung gleich false

ansonsten Einrückung, usw. laut Visual Studio.

PS: In Visual Studio Schriftgrad 9, anstatt 10 😉

Ich mach das so wie kleines_eichhoernchen, verwende aber auch regions... 😉

Update: Hm, doch nicht ganz, ich verschwende mehr Platz...
Ich machs eigentlich ganz genauso wie der User unter mir, Khalid.

Also, ich verschwende viel Platz und schreibe jede Anweisung in eine Zeile. Bei Methoden mit mehr als zwei Parametern, schreibe ich jeden Parameter in eine neue Zeile.
Hier mal Beispiele:

Die geschweiften Klammern immer in eine extra Zeile:

public class Test
{
  public string Bla(int i)
  {
    if (i == 0)
    {
      // Anweisung
      // Anweisung
      return "A";
    }
    else
    {
      // Anweisung
      // Anweisung
      return "B";
    }
  }
}

Jede Anweisung kommt in ihre eigene Zeile:

public bool Bla(int i)
{
  if (i == 0)
    return "A";
}
// anstatt
public bool Bla(int i)
{
  if (i == 0) return "A";
}

Bei vielen Parametern, kommt jeder Parameter in eine eigene Zeile:

public void MethodeMitVielParams(int a, int b, string c, string d, bool e)
{
  //
}
// Aufruf:
public void Foo()
{
  MethodeMitVielParams(
    1,
    2,
    "A",
    "B",
    false);
}
// ist IMHO besser zu lesen als z.B.
public void Foo()
{
  MethodeMitVielParams(1, 2, "A",
    "B", false);
}

Und mit Regions arbeite ich auch, diese lasse ich mir allerdings autom. generieren (Regionerate).

in der Regel progge ich recht platzverbrauchend:

foreach (Control c in this.Controls)
{
    if(c.Controls.Count > 0)
    {
        MessageBox("asdf jklö");
    }
}

hier kann man auf einen Blick die hierarchische Struktur erkennen... einfach besser zu lesen

einzige Ausnahme: einfache Abfragen gestalte ich immer öfter so:

string s = a < b ? "asdf" : "jklö"

EDIT: Tippfehler

Hallo Sweet,

siehe Code layout

herbivore

Hallo zusammen,

ich brauche auch sehr viel Platz.
Bei mir bekommte jede Klammer, Anweisung usw. ihre eigene Zeile.

Eine Ausnahme mache ich jedoch bei den Getter-Settern

private int _MyInt;

/// <summary>
/// Auch kommentare sind mir wichtig
/// <summary>
public int MyInt
{
    get { return _MyInt; }
    set { _MyInt=value; }
}

Einfache Anweisungen verwende ich sehr selten, da ich es übersichtlicher finde die Klammern zu verwenden.

Auch die Regions verwende ich sehr oft, wobei ich die einzelnen Methoden und Variablendeklarationen in verschiedene Regions unterteile.

Also habe ich folgende Regions:1.Private Properties 1.Public Properties 1.Delegates 1.Events 1.Util-Methods

Anschließend kommen natürlich noch weitere Regions dazu, die jedoch von Projekt zu Projekt unterschiedlich sind. Also größere Arbeitsschritte packe ich wieder in eine Region.

Gruss
Michael

Vorweg,
die Bezeichnungen Platzverbrauch(Allman)-Stiel sowie Platzsparender (1TBS/K&R)-Stil sind ja grausig 😉

Ich stimme euch zu, dass die Schreibweise nach Allman bei kleinen bis normalen Dateien doch übersichtlicher sein kann als 1TBS/K&R. Allerdings hat die Lang-Schreibweise Allman den Nachteil bei großen Dateien mit mehreren 1.000 Zeilen Code. Dort ist es schwieriger mit bloßem Auge nachzuvollziehen, wo ein Block anfängt und wo er aufhört. Bei K&R ist das anders, nicht nur weil dadurch 100 Zeilen und mehr eingespart werden können, sondern der Code ist dadurch kompakter, leicht ersichtlich wo der Block anfängt und aufhört. Weiterhin passt mehr auf eine Bildschirmseite durch Verwendung von K&R, was die Suche und Überprüfung von bestimmten Code-Teilen stark erleichtert.

Was hier aber noch nicht besprochen wurde, wie rückt ihr ein? Ich persönlich nutze Tabuloren (werden nicht in Leerzeichen umgewandelt) mit einer Breite von 1 oder Zeichen

Was hier aber noch nicht besprochen wurde, wie rückt ihr ein? Ich persönlich nutze Tabuloren (werden nicht in Leerzeichen umgewandelt) mit einer Breite von 1 oder Zeichen

Genau so habe ich es auch. Ich verwende aber eine Breite von 2.

Gruss
Michael

Tabulatoren mit zwei Zeichen Einrückung (vier finde ich zu viel und wird unleserlich). Achja, und die Tabs werden auch nicht in Leerzeichen umgewandelt.

resharper-standard einstellung.

Dito.

Eingerückt mit 4 Spaces. Früher habe ich immer Tabs genommen, aber mittlerweile bin ich überzeugt, dass Spaces wesentlich praktischer sind.

PS:
Für XML/XAML habe ich mich irgendwie in ein neuen Stiel verliebt, jede Eigenschaft in eine neue Zeile (kann man in VS auch einstellen). Ist allerdings eher exotisch, glaube ich. Das sieht dann so aus:

<Menu x:Name="mainMenu"
      DockPanel.Dock="Top">
    <MenuItem Header="Database">
        <MenuItem Header="Compress"
                  Command="local:Commands.CompressDatabase" />
    </MenuItem>
    <MenuItem Header="Help" />
</Menu>

Hallo,

Allerdings hat die Lang-Schreibweise Allman den Nachteil bei großen Dateien mit mehreren 1.000 Zeilen Code.

Bei den meisten Projekten im kritischen Umfeld (Luftfahrt,Medezin,...) gibt es noch die Regel das eine Methode auf eine Bildschirmseite passen muss. Ich habe dass für mcih so übernommen und ich muss sagen es ist wirklich toll. Aber manchmal siegt halt die Faulheit. 😜

Gruss
tscherno

gibt es noch die Regel das eine Methode auf eine Bildschirmseite passen muss.

es gilt im allgemeinen als guter stil und wird auch von microsoft so empfohlen. es gibt ncihts schlimmeres, wie eine methode mit mehr als 100 zeilen.. ich hatte mal in einem projekt eine methode, die hatte knapp 2000 zeilen... wir haben eine gute woche gebraucht um das wieder in eine vernünftige form zu bringen. das problem an so langen methoden ist die fehersuche und die mangelhafte übersichtlichkeit (spielt ja beides zusammen...)

Hallo JAck30lena,

die Regel ist grundsätzlich ratsam. Es gibt aber auch Umstände, die es günstiger erscheinen lassen, davon abzuweichen, insbesondere wenn die Aufteilung einer langen Methode, die viele lokale Variablen nutzt, dazu führt, dass an die Einzelmethoden lange Listen von (ref-)Parametern übergeben werden müssen. Außerdem kann man die Notwendigkeit einer Aufteilung mindern, wenn man logische Abschnitte in der Methode durch gut sichtbare Kommetarblöcke trennt. Es reicht dann, wenn ein solcher logischer Abschnitt auf einen Bildschirmseite passt. Zu guter Letzt sollte man nur dann aufteilen, wenn die Einzelmethoden in sich abgeschlossene Aufgaben erfüllt werden, die außerdem sinnvoll benannt werden können. Wenn man zwanghaft aufteilt und dann so Methodennamen wie "Initialisierung", "Aufbereitung" und "Schleifenrumpf" rauskommen, ist nichts gewonnen.

herbivore

prinzipiell hast du schon recht nur wir haben damals einige redundanzen gesehen, die nicht nachgepflegt wurden usw... und bei so einem code wird mir eifach nur schlecht. eine große methode sollte eine ausnahme beleiben und dennoch wenn möglich vermieden werden, da man sie nicht nur schlecht pflegen kann, man kann sich auch schlecht mit tests abdecken. es ist einfach schöner wenn ich eine kleine methode habe und ein oder zwei testfälle durchjage und mir somit sicher sein kann das sie geht, als eine große methode, die im fehlerfalle erstmal länger analysiert werden muss, warum sie nciht geht.

natürlich gibt es auch in diesem fall keine allgemeingültige aussage. in manchen fällen muss man einfach eine große methode haben, da stimme ich dir auch zu aber in den meisten fällen ist es in einem vernünftigen rahmen zu vermeiden.

Hallo JAck30lena,

und bei so einem code wird mir eifach nur schlecht. eine große methode sollte eine ausnahme beleiben und dennoch wenn möglich vermieden werden, da man sie nicht nur schlecht pflegen kann,

das stimmt in dieser Pauschalisierung nicht und ich denke dir würde auch nicht schlecht werden, wenn du eine größere Methode von mir siehst, die durch Kommentare in logische Blöcke unterteilt ist. Viel eher würde mir schlecht werden, wenn ich mich mit Methoden wie Initialisierung", "Aufbereitung" und "Schleifenrumpf" rumschlagen müssen. Ob man die dann leichter testen kann, bliebe abzuwarten. Ich wollte ja auch nicht mehr sagen als: "keine Aufteilung um jeden Preis". Und kein pauschales verunglimpfen von langen Methoden.

herbivore

oh man... ich fall da ja vollkommen aus den Rahmen.... :

if(true) {
     //Anweisung..
}

//bei switches
switch(iwas) {
     case X: {
          //Anweisung...
         break;
     }
}

zusätslich habe ich mir es angewöhnt komplizierte code-blöcke in eigene Scopes zu verlagern... durch das einrücken kann ich das viel besser lesen.. (meine meinung^^)

Hallo,

mit den Einrückungen versuche ich mich an die gängige Konventionen der jeweiligen Platform anzupassen.

//C#
public int MyMethod(int firstValue,int secondValue)
{ 

    //CODE

}

//Java

public int myMethod(int firstValue,secondValue){

   //CODE;

}

Gruss
tscherno

Ich benutze Regions.

Verwend ich auch viel...

Welche Möglichkeiten gibt es eigtl. veraschachtelte generische Typen "leserlich" darzustellen? Beispiel

Dictionary< string, Dictionary < Object, List < IEnumerable < string > > > > type = Dictionary< string, Dictionary < Object, List < IEnumerable < string > > > > ();

Hallo kleines_eichhoernchen,

ich schreibe runde, eckige und spitze Klammern immer so, wie es in normalen deutschen Text üblich ist: vor öffnenden Klammern mit Leerzeichen, dahinter ohne und bei schließenden Klammern davor ohne Leerzeichen, dahinter Satzzeichen direkt dran und Nicht-Satzzeichen mit Leerzeichen getrennt. Also

Dictionary <string, Dictionary <Object, List <IEnumerable <string>>>>

Die von dir angegebene Schachtelung ist ja schon ziemlich extrem. In der Praxis wird sowas selten vorkommen.

herbivore

Welche Möglichkeiten gibt es eigtl. veraschachtelte generische Typen "leserlich" darzustellen? Beispiel

  
Dictionary< string, Dictionary < Object, List < IEnumerable < string > > > > type = Dictionary< string, Dictionary < Object, List < IEnumerable < string > > > > ();  
  

Ab C# 3.0 für die linke Seite das Schlüsselwort var verwenden, das halbiert den benötigten Platz schon mal fast ...