Wie formatieren Sie Ihre zusammengesetzten Anweisungen in Delphi und C#?

Question

Wie lange Pascal und Delphi Entwickler, ich beginnen immer in einer Reihe aufstellen und damit endet:

begin 
    if x = y then 
    begin 
    ... 
    ... 
    end 
    else 
    for i := 0 to 20 do 
    begin 
     ... 
     ... 
    end; 
end; 

Was Nüsse treibt mich ist also Code formatiert:

begin 
    if x = y then begin 
    ... 
    ... 
    end 
    else 
    for i := 0 to 20 do begin 
     ... 
     ... 
    end; 
end; 

Wenn es ein paar Stufen von zusammengesetzten Aussagen finde ich das schwer zu lesen. Der obige Code ist in Ordnung, weil es nicht so kompliziert ist, aber aus Gründen der Konsistenz würde ich alle Anfangs- und Endpunkte vorziehen.

Als ich C# benutze, finde ich mich auch geschweifte Klammern ausrichten. Was ist die Norm in der C# -Welt?

Edit:

Jemand hat darauf hingewiesen, dass dies die Art von Frage, die so sein sollte nicht gebeten. Ich verstehe nicht warum nicht. Ich bin dabei, ein Kodierungsrichtliniendokument zu erstellen. Ich weiß, dass ich gewisse Widerstände gegen bestimmte Dinge bekommen werde, ich hoffe, hier ein paar Antworten zu bekommen, damit ich bereit bin, diesem Widerstand frontal zu begegnen.

Answer 1

Jeder hat andere Vorlieben. In meinem Fall habe ich Modula-2 gelernt, bevor ich Pascal gelernt habe. Modula-2 hat kein BEGIN-Schlüsselwort und ein erforderliches END für jeden Block. So Code könnte wie folgt aussehen (Modula-2 geschieht Groß- und Kleinschreibung mit Groß Schlüsselwort zu sein):

IF x = y THEN 
    .... 
END; 

Wenn ich in Pascal zu codieren begann, wurde dies:

if x = y then begin 
    .... 
end; 

Auf diese Weise des Code sah eher so aus, wie ich es gewohnt war zu sehen, während er immer noch im Bereich des akzeptablen Pascal-Codes lag.

Für mich haben diese frühen Impressionen meine bevorzugte Klammer und den Einzugsstil für praktisch alle anderen Sprachen beeinflusst, mit denen ich gearbeitet habe. Es gibt nicht wirklich eine bestimmte "Norm" für C# -Code, genauso wie es für C oder Pascal keine gibt.

Die einzige wirkliche Regel, die zu befolgen ist, ist diese: Wenn Sie an existierendem Code arbeiten, verwenden Sie den Stil, der bereits existiert. Wenn Sie an neuem Code arbeiten, verwenden Sie Ihren bevorzugten Stil.

Answer 2

Dies wurde zuvor gefragt. zum Beispiel c-coding-standard-best-practices.

Answer 3

Ich würde nie den Code (Ihr zweites Beispiel) auf diese Weise schreiben. Es wäre entweder (bevorzugt)

begin 
    if x = y then begin 
    ... 
    end 
    else begin 
    for i := 0 to 20 do begin 
     ... 
    end; 
    end; 
end; 

oder

begin 
    if x = y then begin 
    ... 
    end 
    else for i := 0 to 20 do begin 
    ... 
    end; 

Ende sein;

Manchmal benutze ich solche kollabieren (wie im zweiten Fall) zu kombinieren, wenn und versuchen..finally.

x := GetMeTheObject; 
if assigned(x) then try 
    ... 
finally FreeAndNil(x); end; 

Answer 4

habe ich eine "baumelnde" beginnen in Delphi zu verwenden:

if (SomeCondition) then begin 
    ... 
end; 

Merkwürdigerweise habe ich nicht mit C, weil ich diese besser lesbar gefunden:

if (SomeCondition) 
{ 
    ... 
} 

Nach einer Weile habe ich aufgehört, zu versuchen, eine einzige Zeile hier und da zugunsten der Lesbarkeit zu speichern:

if (SomeCondition) then 
begin 
    ... 
end; 

Ich verwende auch explizite Anfangs-/Endblöcke, wo ich denke, dass es die Lesbarkeit verbessert. Ich muss nicht "schlau" sein. Ich muss in der Lage sein, die Absicht des Codes auf einen Blick zu verfolgen. Noch wichtiger ist, dass jeder, der es lesen/pflegen könnte.

if x = y then 
begin 
    ... 
    ... 
end 
else 
begin 
    for i := 0 to 20 do 
    begin 
    ... 
    ... 
    end; 
end; 

ich in der Regel nicht die Mühe machen, wenn es offensichtlich eine einzige Aussage ist

if (SomeCondition) then 
    ... 

Answer 5

Ich persönlich benutze:

if Condition then 
begin 
    DoThis; 
end else 
begin 
    DoThat; 
end; 

Object Pascal Style Guide See.

In Verbindung if-Anweisungen, setzen jedes Element Aussagen über ein neues Trennlinie: Beispiel:

// INCORRECT 
if A < B then begin 
    DoSomething; 
    DoSomethingElse; 
end else begin 
    DoThis; 
    DoThat; 
end; 

// CORRECT 
if A < B then 
begin 
    DoSomething; 
    DoSomethingElse; 
end 
else 
begin 
    DoThis; 
    DoThat; 
end; 

Hier sind ein paar mehr Varianten, die als gültig betrachtet werden:

// CORRECT 
if Condition then 
begin 
    DoThis; 
end else 
begin 
    DoThat; 
end; 

// CORRECT 
if Condition then 
begin 
    DoThis; 
end 
else 
    DoSomething; 

// CORRECT 
if Condition then 
begin 
    DoThis; 
end else 
    DoSomething; 

Answer 6

Pro Sonally, ich bevorzuge Komprimierung von Aussagen in einer Zeile. Z.B. end else in einer Zeile. Macht es klarer, dass der nächste Block von Aussagen sich auf den aktuellen bezieht.

Answer 7

Ich neige dazu, dies in Delphi zu tun:

if a=b then begin 
    c; 
end else begin 
    d; 
end; 

if x=y then z; 

einfach, weil ich es besser lesbar als mit den zusätzlichen Zeilenumbrüchen finden. Wenn ich mit anderen arbeite, werde ich selbstverständlich die Standards verwenden, auf die wir uns verlassen (oder was auch immer die aktuelle Codebasis verwendet), aber wenn ich der Einzige bin, der daran arbeitet (wie in persönlichen Projekten), dann So mach ich es.

Answer 8

Norm in der C-Welt ist Schließung Klammern entweder mit der Start Anweisung auszurichten:

if (I am nuts) { 
    Psychiatry 
} 

oder sogar legt die öffnende Klammer in einer eigenen Zeile:

if (I am nuts) 
{ 
    Psychiatry 
} 

In einigen Arten, die Klammern haben unterschiedliche Einbuchtung:

if (I am nuts) 
    { 
    Psychiatry 
    } 

oder sogar

if (I am nuts) 
    { 
    Psychiatry 
    } 

verwendete ich den ersten Stil für eine lange Zeit in Perl, und das war mein Weg für die sonst Fortsetzung:

if (I am nuts) { 
    Psychiatry 
    } else { 
    I am free 
} 

aber nach dem Lisp ausgesetzt war, habe ich keinen zusätzlichen Wert sehen davon ab, die Klammern auf ihre eigene Linie, wenn ich bin schon Einrücken richtig:

if (I am completely nuts) { 
    Psychiatry } 
    else { 
    I am free } 

ich habe keine Hoffnung, die traditionellen C Wege mit diesen Gedanken zu ändern, though. Als Nebenbemerkung hat Python die Klammern komplett weggeworfen und verlässt sich nur auf Einrückung, aber das geht meiner bescheidenen Meinung nach zu weit, da es zu so lächerlichen Dingen wie dem führt, dass Lambda nur eine Aussage haben kann.

Answer 9

Jemand gepostet, dass sie folgendes schreiben würde:

if x=y then z; 

Nun ist dieses Ich mag es nicht wirklich, und es ist nichts mit Ästhetik zu tun. Nehmen wir an, dass x, y und z Funktionen sind. Wenn ich den Code durchtrete, bedeutet das oben, dass ich nicht über x und y hinweggehen und in z gehen kann.

1 if x=y then 
2  Z; 

ich jetzt in der Leitung 2 ohne Einsteigen in Zeile 1

Answer 10

Schritt kann ich in einer Reihe aufstellen immer den Start/kurz wie in Ihrem Beispiel. (Außer ich hätte auch ein Begin/End um die For-Anweisung - nur für den Fall, dass Sie Code später hinzufügen.)

Wie auch immer, wenn Ihr Code mehrere Ebenen tief ist, dann spielt es keine Rolle, wo Sie sind setze dein Anfang/Ende, da es zu kompliziert ist. Wenn du dich etwa 3 Stufen tief fühlst, hör auf und vereinfache. Erstellen Sie Subroutinen, um Dinge zu bereinigen.

CodeComplete ist das beste Buch der Referenz auf diese Art von Sache. Wenn du etwas nicht lernst, das dieses Buch liest, dann werde ich meinen Hut essen.

Answer 11

Vor einiger Zeit habe ich

if <cond> then 
    begin 
    ShowMessage('balablala'); 
    exit; 
    end; 

Aber jetzt folge ich dem Standard der

if <cond> then 
begin 
    ShowMessage('balablala'); 
    exit; 
end; 

Wie in Object Pascal Style Guide

Answer 12

Ich neige dazu, immer meine IF aufreihen und ELSE und indent mein BEGIN/END-Block. Wenn ich eine IF mit mehreren Bedingungen habe, breche ich diese in mehrere Zeilen auf.Wenn ich finde, dass ich selbst zu tief komme, dann überlege ich, was ich kodiere oder transformiere es in mehrere Methoden. So sieht mein Code wie folgt aus:

if condition1 then 
    begin 
    // do something 
    end 
else // not condition1 
    begin 
    // do something else 
    end; 

oder die komplexere wenn Bedingungen.

if condition1 or 
    condition2 or 
    condition3 and 
    (condition4 or 
    condition5) 
then 
    begin 
    // do something 
    end 
else // not conditions 
    begin 
    // do something else 
    end; 

Answer 13

Das ist alles ziemlich lustig. Ich habe meine eigene idiosynkratische Art der Ausrichtung, die ich seltsamerweise in mehreren Sprachen verwende, einschließlich Pascal, C und sogar COBOL (wenn auch nicht lange her).

Ich glaube, ich sah es zum ersten Mal in einer Klasse von Ken Orr. Meine Version ist auch sehr ähnlich wie eine Abseitsregel (ähnlich wie Python und F #), wo Sie einfach die Einrückung verwenden können, um die Verschachtelung anzuzeigen.

Wie auch immer, hier ist, wie ich das Beispiel tun:

begin if x = y 
     then begin (* stack to avoid getting too much indentation *) 
      ...  
      ... 
      end 
     else for i := 0 to 20 
      do begin  
       ...  
       ...  
       end; 
     end; 

und ja, die C/C++/Java/C# Geschmack etwas wie

{ if (x == y) 
      { ... /* Space as if 'then' is there */ 
      ... 
      } 
    else for (int i = 0; i<21; i++) 
       { ... /* space as if 'do' is there */ 
       ... 
       } 
    } 

ich diese verwenden viel sein würde. Du könntest genauso stapeln, wie ich begonnen und beendet habe, aber ich finde es angenehmer, in der Lage zu sein, eine Kante zu sehen und übereinstimmende Klammern und das Ende der eingerückten Gruppe zu bestätigen. Ich variiere, um zu verhindern, dass ich übermäßig bin, und zu vermeiden, dass zu viele "{" und "}" in einem Meer aus Leerzeichen stehen.

Ich missioniere das nicht. Niemand hat sich darüber beschwert, dass er es lesen kann. Putting "{" am Ende einer Zeile erscheint wie ein Überfall von Ratfor Pre-Prozessoren und so, wie Python die (angenehmeren) ":" an einigen Stellen benötigt. Ich möchte nicht den rechten Rand nach unten scannen müssen, wenn ich die Ausrichtung an den linken Kanten sinnvoller verwenden kann.

Wie wir sagen hier, YMMV

Answer 14

einige Code-Formatierer wie JEDI-Code Format von http://jedicodeformat.sourceforge.net/

Answer 15

Selbst verwenden, wenn es mir immer innerhalb if, eine einzelne Anweisung ist verwenden Verbindung begin-end zukünftige Verwirrung zu vermeiden.
Auch ich setze // if nach jedem end;.

if A < B then 
begin 
    DoSomething; 
end; // if 

Das Gleiche gilt für andere Aussagen:

with qryTemp do 
begin 
    First; 

    while not Eof do 
    begin 
    if (A < B) 
     or (C < D) 
    begin 
     DoSomething; 
    end else 
    begin 
     DoSomethingElse; 
    end; // if-else   

    Next; 
    end; // while 
end; // with 

für C#, ich folge Code Conventions for the Java Programming Language Stil zusammengesetzte Anweisungen.

if (condition) { 
    statements; 
} // if 

if ((condition1 && condition2) 
     || (condition3 && condition4) 
     ||!(condition5 && condition6)) { 
    doSomethingAboutIt(); 
} else { 
    doSomethingElse(); 
} // if-else 

Für Delphi und C#, kommen die Verbindungs ​​logischen Operatoren am Anfang der nächsten Zeile.

Answer 16

Ich bin ein Wochenendprogrammierer, also bin ich der Einzige, der an den Projekten arbeitet. Ich kann es mir leisten, nicht einer bestimmten Kodierungskonvention zu folgen, ich bin glücklich.

Wenn es um Codelesbarkeit geht, ist Castalia's structural highlighting sehr nützlich. CnPack hat eine ähnliche Funktion ist ich nicht verwechseln.

Answer 17

Hah! Nimm das! ;)

try 
    if Condition1 
    or ( Condition2 
     and Condition3) then 
    begin 
     DoSomething 
     DoSomeMore; 
    end 

    else if Condition4 then // I only do this if the nested "if" has "case"-like characteristics 
    begin     // otherwise the if would obviously be indented and on its own line 
     DoSomethingElse; 

     if Condition5 then 
     begin 
      DoThisToo; 
      DoFoo; 
     end; 
    end 

    else 
    DoTheWholeShebang; 

    case Whatever of 
    A: DoIt; 

    B, C, D: 
     begin 
     DoSomethingSlightly; 
     MoreComplicated; 
     end; 

    else 
    begin 
     DoWhatever; 
     DoLastResort; 
    end; 
    end; 
except 
    on ESomeException do 
    begin 
     HandleIt; 
     raise; 
    end; 
    on ESomeOtherException do 
    DealWithIt; 

    else 
    DoWhateverItTakes; 
end; 

Merkwürdig zwar, wenn sie in geschweiften Klammern Sprachen zu schreiben Ich ziehe auch die hintere Klammer Layout:

if (condition) { 
    doSomething; 
} else { 
    doSomethingElse; 
} 

Answer 18

lassen Sie Ihre IDE-Einzug für Sie in den meisten Fällen.

Answer 19

Ich finde den Code besser lesbar, wenn die Schlüssel Wörter (Schlüssel sowohl syntaktisch als auch logisch) so viel wie möglich ausgesetzt sind.

Das ist so wichtig für mich, dass ich manchmal (IMO) ziemlich unkonventionelle Sache nehme.

Hier ist, was es wird, wie:

if (condition) then begin 
    statement; 
    ... 
    statement; end 
else begin 
    ... 
end; 

Ich gebe zu, das es den Code ein bisschen weniger bequem machen zu ändern. Es ist nur, dass ich die 'baumelnden' end in der Mitte einer if Aussage finde, und ausgerichtet wie die if, etwas verwirrend. Wenn es end ist, muss es das letzte sein (für die Aussage), andernfalls erwarte ich entweder else oder den Anfang der nächsten Aussage an dieser Position.

Und ich lasse es normalerweise nicht sein, wenn der then Block zusammengesetzt ist, aber der else man ist eine einzelne Aussage. Das ist nie eine große Sache mit mir, um den Zustand zu invertieren und die Blöcke neu anzuordnen. Noch mehr, da ich ziemlich tight bin, wenn es darum geht, eine einzige Aussage mit begin ... end s einzuwickeln. Aus meiner Sicht und Erfahrung, sind reichlich 'Anfang-Ende sind überflüssig' Anfang oft mehr als nicht. Obwohl ich es mag, wenn eine Aussage ein explizites Schlusswort hat, so sind meine case und repeat meine absoluten Favoriten. :)

Eine weitere Sache über if s (und while s für diese Angelegenheit) ist, dass im Falle eines zig Decker Zustand neige ich then (do) in der nächsten Zeile platzieren und ausgerichtet auf die Start Schlüsselwort Aussage .

So:

if (some_long_conditional_expression) or 
    (some_other_long_conditional_expression) or 
    (some_even_longer_conditional_expression) 
then 
    Exit; 

Auch gibt es einige andere Dinge hier bereits erwähnt, die ich keine Ausländer bin, wie einzeilig else if s (bei Bedarf) oder for ... do with ... do try s (ja, das kann wieder habe etwas mit meiner oben erwähnten engen Fisting-Natur zu tun).

Im Großen und Ganzen würde ich wahrscheinlich zu viel auf Code-Hervorhebung und Einrückung, vor allem der letzteren, verlassen. Vielleicht würde ich, wenn es nicht für den Einzug wäre, bevorzugen, immer die begin s herauszugreifen.

Ein weiterer Punkt: jemand Formatierungsstil kann sehr wahrscheinlich durch ihren Programmierstil verursacht werden. Manche Leute hassen sehr große Routinen und tendieren zu Faktoren, wann immer es möglich ist, während andere sich lieber auf den Code selbst konzentrieren und diese verschiedenen bildschirmübergreifenden zusammengesetzten Blöcke nicht beachten - ich finde, dass dies sehr unterschiedliche Ansätze sind, die zu unterschiedlichen Formatierungsgewohnheiten führen können .