Laden...

Code layout

Erstellt von VizOne vor 19 Jahren Letzter Beitrag vor 19 Jahren 5.579 Views
VizOne Themenstarter:in
1.373 Beiträge seit 2004
vor 19 Jahren
Code layout

[abgetrennt von Test ob Object Methode exportiert]

Original von nba

  
if(sender is Control)  
{  
        (sender as Control).Focus();  
}  
  

[...]
die extra Zeile f. d. Klammer muß aber sein 😉

Das hab ich auch immer gedacht, bis ich Code Complete gelesen habe. Da wurde mir klar, dass es nicht die logische Struktur des Codes wiedergibt. Seitdem schreibe ich meine öffnenden Klammern brav am Ende der Zeile 😁

MfG VizOne

49.485 Beiträge seit 2005
vor 19 Jahren

Hallo VizOne,

nach dem das eigentliche Thema ja wohl abgeschlossen ist, können wir uns ja ruhig auf das Offtopic stürzen. Schon lustig, wie heftig ich mich in meinem Leben schon über Klammern gestritten habe 🙂

Aber jetzt erstmal ganz schlich: Mich würde interessieren, wie 'Code Complete' begründet, dass die logische Struktur besser wiedergegeben wird, wenn man die öffnenden Klammern mit auf die Zeile schreibt.

Wie hält es 'Code Complete' mit öffnenden Klammen von Klassen und Methoden (die schreibe ich nämlich auf eine extra Zeile; kleines Relikt aus C-Zeiten, wo das diese Klammern dann ja in Spalte eins standen)?

Außerdem wäre ich interessiert weitere (fundierte) Begründungen für die eine oder andere Art der Formatierung zu hören, z.B. 'if(bed) vw. if (bed)'.

Vielen Dank!

herbivore

VizOne Themenstarter:in
1.373 Beiträge seit 2004
vor 19 Jahren

The Fundamental Theorem of Formatting says that good visual layout shows the logical structure of a program.

Es geht darum, den logischen Fluss des Codes optisch wiederzugeben.

Eine Kontrollstruktur (z.B. if) läutet einen neuen Code-Block ein, der entsprechend optisch erkennbar sein sollte. Ich habe ein Bild angehängt, welches zwei mal einen logisch gleichen if-block enthält, nur sind jeweils die Klammern anders gesetzt.
Im oberen Teil ist jeweils der if-block als code zu sehen, darunter die optische Erscheinung für den Leser. In welchem der beiden Bilder entspricht die optische Erscheinung dem logisch Fluss des Codes? Klar: im zweiten. Im ersten hat man das Gefühl, dass das if-statement losgelöst von dem Block steht, den es eigentlich einleitet.

Das Prinzip gilt auch für Klassen usw. Im Buch werden auch noch alternative Möglichkeiten besprochen die den Codefluss optisch gut wiedergeben, etwa:


if( foo > 4) 
   {
   CloseApp();
   DestroyWorld();
   GoHome();
   }

Aber die sind doch eher ungebräuchlich.

Was die Leerzeichen angeht: wenn auch der Parser gut ohne zusätzliche Leerzeichen zurecht kommt, ich mag es lieber "luftig" - ist für mich besser lesbar.

Natürlich ist das auch eine Geschmacksfrage, und jeder hat da eine andere Meinung zu. Aber ich finde die Argumentation schon einleuchtend. Am wichtigsten ist natürlich, dass ein Code-Layout konsequent benutzt wird, vor allem, wenn mehrere Personen am Quellcode mitarbeiten.

MfG VizOne

X
2.051 Beiträge seit 2004
vor 19 Jahren

@VizOne: Glückwunsch zu deiner "Ersten Aktion als Moderator" ! 😁

also für mich ist der obere Teil logischer.

Beim unteren Teil sieht die Zeile

DestroyWorld(); 

so aus, als ob sie überhaupt nicht mehr zu if gehören würde, weil die { am Ende des if einfach übersehen wird. Wenn { in neuer Zeile steht, dann sehe ich sofort, dass if Block aus mehreren Anweisungen besteht und nicht nur aus einer.

Aßerdem sieht die offene Klammer in der gleichen Zeile zu JAVA-mässig aus. 8)

P
939 Beiträge seit 2003
vor 19 Jahren

Also ich schreibe die öffnende Klammer lieber in die gleiche Zeile (allerdings komme ich auch aus der Java-Sektion 😉 )

Wie sieht es denn hiermit aus?

if(foo > 4)
{
  foo = 5;
}
else if(foo < 1) 
{
  foo = 4;
}
else
{
  foo = 0;
}

Mir ist das zu lang. Ich schreibe es lieber kompakt als:

if(foo > 4) {
  foo = 5;
} else if(foo < 1) {
  foo = 4;
} else {
  foo = 0;
}

Mit Kommentaren würde es so aussehen:

// Fall 1
if(foo > 4) {
  foo = 5;

// Fall 2
} else if(foo < 1) {
  foo = 4;

// Default
} else {
  foo = 0;
}

Zwar steht der Kommentar, wenn man es ganz genau nimmt, im falschen Block, aber es ist trotzdem gut lesbar.

Wenn man die Code-Konventionen beachtet (nach denen öffnende Klammern in neue Zeilen gehören) und vor jedem Kommentar eine Leerzeile lässt, sieht das erste Beispiel mit Kommentaren so aus.

// Fall 1
if(foo > 4)
{
  foo = 5;
}

// Fall 2
else if(foo < 1) 
{
  foo = 4;
}

// Default
else
{
  foo = 0;
}

Eindeutig zu lang und nicht besonders gut leserlich, finde ich.

Gruss
Pulpapex

VizOne Themenstarter:in
1.373 Beiträge seit 2004
vor 19 Jahren

Ich komme eigentlich nicht aus der Java-Ecke, und als ich mit Java angefangen habe, gingen mir die Klammern am Ende der Zeilen ziemlich auf den Keks. Aber nachdem ich mich davon habe überzeugen lassen (durch das Buch und die Praxis), will ich nicht mehr zurück. Der Code ist, wie Pulpaplex schon sagt, kompakt und doch gut leserlich.

Beim unteren Teil sieht die Zeile

  
DestroyWorld();  
  

so aus, als ob sie überhaupt nicht mehr zu if gehören würde, weil die { am Ende des if einfach übersehen wird. Wenn { in neuer Zeile steht, dann sehe ich sofort, dass if Block aus mehreren Anweisungen besteht und nicht nur aus einer.

Da ich prinzipiell bei jeder Kontrollstruktur Klammern mache (auch bei Einzeilern), kommt bei mir da keine Verwirrung auf. Die Zugehörikeit der jeweiligen Zeilen wird aber in jedem Fall schon durch die Einrückung unterstrichen. Eine gute automatische Indentierung (wie die von VS) hilft hier Fehler zu vermeiden.

Ich finde es übrigens eine grandiose Neuerung von VS.NET2005, dass man sehr fein einstellen kann, wie der Sourcecode formatiert werden soll. Strg-E, Strg-D, und schon ist der Code sauber und ordentlich, inkl. Leerzeichen, Klammern usw. Was noch fehlt wäre eine Batchfunktion, mit der man alle Dateien eines Projekts reformatieren kann - aber da gibt es bestimmt bald ein Plug-in für.

MfG VizOne

X
2.051 Beiträge seit 2004
vor 19 Jahren

für if's nur mit einer Anweisung sieht das wirklich etwas zu lang aus. Da kann man aber Klammern gleich ganz sparren:

 
// Fall 1
if (foo > 4)
  foo = 5;
// Fall 2
else if (foo < 1)
  foo = 4;
// Default
else
  foo = 0;

oder auch so:

 
// Fall 1
if (foo > 4) foo = 5;
// Fall 2
else if (foo < 1) foo = 4;
// Default
else 
  foo = 0;

da ist das Problemm mit offener Klammer gleich aus der Welt geschafft. 😁

4.207 Beiträge seit 2003
vor 19 Jahren

Hallo,

die Klammern bei Einzeilern wegzulassen, halte ich allerdings für gefährlich. Man erweitert mal den Code, übersieht, dass da eben keine Klammern stehen, und schon hat man das Malheur.

Ich schreibe die Klammern jeweils in eine eigene Zeile, schreibe auch bei Einzeilern Klammern, und mein Gott, wenn es dadurch ein wenig länger wird, was soll's? Mit 800 x 600 entwickelt ja wohl kaum noch jemand 😉 ...

Viele Grüße,

Golo

Wissensvermittler und Technologieberater
für .NET, Codequalität und agile Methoden

www.goloroden.de
www.des-eisbaeren-blog.de

F
27 Beiträge seit 2005
vor 19 Jahren

Man möge mir verzeihen, aber dann möchte ich doch auch mal meinen Senf dazu geben ... 🙂.

Ich glaube, die Diskussion, wo welche geschweifte Klammer stehen muss/soll, oder wie viele Leerzeichen man vor eine öffnende Klammer oder innerhalb derselben schreibt, ist ein Fass ohne Boden. Eigentlich macht es jeder anders, und das Schöne ist - eigentlich macht es auch jeder richtig 🙂.

Wo Codeconventions wirklich zum Tragen kommen, ist bei der Arbeit im Team - sie dienen nämlich eigentlich dazu, dass der Code immer gleich aussieht, egal wer ihn schreibt. Dazu gehören ja unter anderem auch Konventionen für die Benennung von Variablen/Klassen/Methoden, ob vor eine Instanzvariable ein m_ geschrieben werden soll oder nicht ... wie gesagt, jeder macht das für sich ja anders.

Natürlich könnte es sein, dass sich jetzt alle auf mich stürzen ... 8o ... aber ich schreibe die öffnenden geschweiften Klammern immer an das Ende der Zeile (des Methodenkopfs/der Klassendeklaration/einer Schleife usw), ich verwende Leerzeichen innerhalb von Klammern ... und das alles genau aus einem Grund: weil diese Art zu programmieren für mich persönlich, rein subjektiv, genau die logische Struktur meines Codes darstellt. Anders ausgedrückt: Den Code, der so geschrieben ist, kann ich schneller erfassen ...

Wie gesagt, wenn ihr euch auf mich stürzen wollt ... 8)

Frank
http://www.frankeller.de
http://blogs.ipona.com/frank

Der Anwender steht immer im Mittelpunkt - und da steht er jedem im Weg.