Formatierung von if-Anweisungen

Question

Dies ist kein heiliger Krieg, das ist keine Frage von "was ist besser".

Was sind die Vorteile der das folgende Format für einzelne Anweisung, wenn Blöcke verwendet wird.

if (x) print "x is true";

if(x) 
    print "x is true";

Im Gegensatz zu

if (x) { print "x is true"; }
if(x) {
    print "x is true";    
}

Wenn Sie formatieren Sie Ihre einzige Anweisung ifs ohne Klammern oder kennen einen Programmierer, der tut, was führte Sie / sie diesen Stil in erster Linie adoptieren? Ich bin speziell interessiert, was nützt dies Ihnen gebracht hat.

Aktualisieren : Da die populärste Antwort ignoriert die eigentliche Frage (auch wenn es den meisten vernünftigen Rat präsentiert), hier ist eine Zusammenfassung der bügel weniger Profis

.

1. Kompaktheit
2. Mehr lesbar einige
3. Halterungen aufrufen Umfang, die einen theoretischen Aufwand in einigen Fällen hat

Answer 1

Das finde ich:

if( true ) {
    DoSomething();
} else {
    DoSomethingElse();
}

besser als diese:

if( true )
    DoSomething();
else
    DoSomethingElse();

Auf diese Weise, wenn ich (oder jemand anderes) später wieder an diesen Code kommt mehr Code zu einem der Zweige hinzuzufügen, ich muss dir keine Sorgen zu vergessen, den Code in Klammern zu umgeben. Unsere Augen werden optisch sehen die Einzüge als Hinweise auf das, was wir zu tun versuchen, aber die meisten Sprachen nicht.

Answer 2

Ich stark jeden Stil nicht mögen, dass der, wenn der Test und Körper auf der gleichen Linie platziert.

Das ist die Linie, weil Sharing macht es unmöglich, einen Haltepunkt auf der, wenn der Körper in vielen Debugger zu setzen, da Stützpunkte typischerweise Zeilennummer basieren.

Answer 3

mit immer Zahnspange ist eine gute Idee, aber die Standard-Antwort, die immer gegeben hat „was ist, wenn jemand eine Zeile Code fügt hinzu und vergisst die Klammern hinzufügen?“ ist ein eher schwacher Grund.

Es gibt einen subtilen Fehler, der durch die nicht die Klammern von Anfang an eingeführt werden können. Es passiert mir ein paar Mal und ich habe es auch für andere Programmierer erlebt.

Es beginnt, ganz harmlos, mit einer einfachen if-Anweisung.

if (condition)
    do_something();
else
    do_something_else();

Welche alles schön und gut ist.

Dann kommt jemand und fügt eine weitere Bedingung für die if. Sie können es nicht fügen die if-Anweisung mit && selbst, weil die Logik falsch wäre, so fügen sie eine andere, wenn. Wir haben jetzt:

if (condition)
    if (condition2)
        do_something();
else
    do_something_else();

Sehen Sie das Problem? Es kann richtig sehen, aber der Compiler sieht es anders aus. Er sieht es wie folgt aus:

if (condition)
    if (condition2)
        do_something();
    else
        do_something_else();

Welche etwas ganz anderes bedeutet. Der Compiler kümmert sich nicht um die Formatierung. Die andere geht mit dem nächsten, wenn. Menschen, auf der anderen Seite, die sich auf der Formatierung und das Problem leicht verfehlen.

Answer 4

ich immer verwenden

if(x) 
{
    print "x is true";    
}

die Klammern auslassen kann jemand führt den Code beibehalten werden fälschlicherweise denken, sie an die if-Klausel hinzufügen, wenn sie eine Zeile nach der aktuellen Zeile hinzufügen.

Answer 5

Ich benutze

if (x)
{
    DoSomething();
}

für mehrere Zeilen, aber ich ziehe bracketless Einzeiler:

if (x)
   DoSomething();
else
   DoSomethingElse();

Ich finde die Fremd Klammern visuell Offensive, und ich habe noch nie gemacht einer der oben genannten Fehler nicht Klammern hinzuzufügen, wenn eine andere Erklärung hinzu.

Answer 6

if
{
// code
}
else 
{
// else code
}

, weil Ich mag, wenn Blöcke von Codezeilen (einschließlich ihren Klammern).

Answer 7

Wenn ich Code:

if(x) 
    print "x is true";

und 6 Monate später braucht eine neue Zeile einzufügen, das Vorhandensein von geschweiften Klammern macht es viel weniger wahrscheinlich, dass ich geben werde

if(x) 
    print "x is true";
    print "x is still true";

, die in einem logischen Fehler führen würde, im Vergleich zu:

if(x) { 
    print "x is true";
    print "x is still true";
}

So geschweiften Klammern machen solche logische Fehler leichter zu lesen und zu vermeiden, finde ich.

Answer 8

Wie Matt (3 oben), ziehe ich:

if (x)
{
    ...statement1
    ...statement2
}

und

if (x)
    ...statement
else
    ...statement

Ich denke, es ist ziemlich seltsam zu denken, dass jemand später kommen kann und erkennen nicht, dass sie die Klammern hinzuzufügen, haben eine mehrzeilige wenn Block zu bilden. Wenn das jenseits ihrer Fähigkeiten ist, frage ich mich, was andere Dinge sind!

Answer 9

Single-Anweisung, wenn Blöcke fehlen Klammern:

Vorteile:

• weniger Zeichen
• cleaner Look

Nachteile:

• Gleichmäßigkeit: nicht alle, wenn Blöcke gleich aussehen
• Potenzial für Fehler, wenn Anweisungen zum Block hinzufügen: a. Benutzer vergessen kann die Klammern und die neue Anweisung nicht durch die, wenn abgedeckt würde hinzufügen

  

Wie in:

if(x) 
    print "x is true";
    print "something else";

Answer 10

Ich neige dazu, sich nur auf einzelne Zeile, wenn ich am Anfang einer Funktion für Pause Bedingungen zu testen bin, weil ich diesen Code so einfach und übersichtlich wie möglich halten möchten

public void MyFunction(object param)
{
     if (param == null) return;

     ...
}

Auch wenn ich finde, ich will Klammern vermeiden und Inline eine if-Klausel Code, ich kann einzelne Zeile ihnen, nur so kann es jedem Hinzufügen neuer Zeilen die offensichtlich ist, wenn die Klammern müssen hinzugefügt werden

Answer 11

ich

if (cond) {
  ...
} else {
  ...
}

• Alles sollte immer Klammern haben. Auch wenn jetzt nur ich eine Zeile in dem if-Block habe, habe ich später mehr hinzuzufügen.
• Ich lege nicht die Klammern auf ihre eigenen Linien, weil es sinnlos Platzverschwendung ist.
• Ich habe selten den Block auf der gleichen Linie wie die bedingte Lesbarkeit zu verbessern.

Answer 12

Joel Spolsky schrieb einen guten Artikel: machen Falscher Code Falsche Schau

Er ist speziell auf dieses Problem ...

if (i != 0)  
    foo(i);

     

In diesem Fall ist der Code 100% korrekt ist;   es entspricht den meisten Codierungskonventionen   und es ist nichts falsch mit ihm, aber   die Tatsache, dass die Single-Aussage   Körper des IFSTATEMENT ist nicht   in geschweiften Klammern Sie werden abgehört können,   weil man in der vielleicht denken   Rückseite des Kopfes, Gosh, jemand   könnte eine weitere Codezeile einfügen   dort

if (i != 0)
    bar(i);
    foo(i);

     

... und vergessen Sie die Klammern hinzuzufügen, und   also versehentlich machen   foo (i) bedingungslos! Also, wenn Sie sehen,   Codeblöcke, die nicht in Klammern sind,   Sie können nur ein winziger, wee spüren,   soupçon von Unsauberkeit, die macht   Sie unruhig.

Er schlägt vor, dass Sie ...

  

... absichtlich Architekt Code   so dass Ihre Nase für   Unsauberkeit macht den Code   wahrscheinlich richtig.

Answer 13

Ich mag nicht Klammern verwenden, wenn sie nicht benötigt wird. Ich fühle mich wie es die Anzahl der Zeilen in einem Verfahren bläht und macht es unlesbar. Also gehe ich fast immer nach folgenden Kriterien:

if (x)
   print "x is true"
for (int i=0; i<10; i++)
   print "y is true"

Und so weiter. Wenn jemand eine andere Anweisung hinzufügen muss, dann kann er nur die Klammern hinzuzufügen. Auch wenn Sie nicht R # oder etwas ähnliches es ist ein sehr kleines Geschäft haben.

Dennoch gibt es einige Fälle, die ich Klammern auch verwenden würde, wenn es nur eine Zeile in der Aussage ist, und das ist, wenn die Leitung besonders lang ist, oder wenn ich brauche Kommentare innerhalb dem, dass ‚wenn‘. Im Grunde habe ich nur verwenden, was schöneres, um meine Augen scheint, zu betrachten.

Answer 14

Leer ist dein Freund ....

aber dann wieder, Ich mag:

if (foo)
{
    Console.WriteLine("Foobar");
}

Answer 15

Im Ernst, wenn das letzte Mal, wenn Sie irgendwo einen Fehler in jedem Code hatten, die war Ursache jemand hat:

if (a)
  foo();
  bar();

Ja, nie ... * Der einzige wirkliche ‚pro‘ ist hier nur den Stil der umgebenden Code übereinstimmen und die ästhetischen Kämpfe um die Kinder zu verlassen, die gerade outta College.

* (als Einschränkung, wenn foo (); bar (), eine Makroerweiterung ist, aber das ist ein Problem w / Makros, nicht geschweiften Klammern w / ifs).

Answer 16

if (x) {
    print "x is true";    
}
else {
    do something else;
}

Ich tippe immer Klammern. Es ist nur eine gute Gewohnheit. Im Vergleich zu denken, ist die Eingabe nicht „arbeiten“.

Beachten Sie das Leerzeichen vor dem bedingten. Das hilft es nicht einen Methodenaufruf wie folgt aussehen.

Answer 17

Andere Möglichkeit wäre, zu schreiben:

(a==b) ? printf("yup true") : printf("nop false");

Dies wird praktisch sein, wenn Sie einen Wert vergleicht einen einfachen Zustand speichern möchten, etwa so:

int x = (a==b) ? printf("yup true") : printf("nop false");

Answer 18

if (x)
{
    print "x is true";
}

Das Öffnen und Schließen Klammer in derselben Spalte macht es einfach nicht übereinstimmen Klammern zu finden, und optisch isoliert den Block. Öffnende Klammer in derselben Spalte wie „wenn“ es leicht zu sehen, macht, dass der Block Teil eines bedingten ist. Der zusätzliche Leerraum um die durch die Zeilen erstellt Block enthält nur macht Zahnspange es einfach, es die logische Struktur herausgreifen, wenn der Code skimreading. Immer explizit Klammern verwenden hilft Probleme zu vermeiden, wenn die Menschen später den Code bearbeiten und falsch verstanden, welche Anweisungen Teil der bedingten sind und welche nicht -. Einbuchtung nicht der Realität entsprechen, aber in Klammern eingeschlossen ist wird es immer

Answer 19

über die einzige Zeit ohne Verspannung in Kauf genommen zu werden scheint, wenn Parametervariablen zu Beginn eines Verfahrens Überprüfung:

public int IndexOf(string haystack, string needle)
{
    // check parameters.
    if (haystack == null)
        throw new ArgumentNullException("haystack");
    if (string.IsNullOrEmpty(needle))
        return -1;

    // rest of method here ...

Der einzige Vorteil ist die Kompaktheit. Der Programmierer muss nicht Throught un-nötig waten {} s, wenn es ganz offensichtlich, dass:

• das Verfahren beendet auf jeden wahren Zweig
• es ist ziemlich offensichtlich, diese sind alle 1-Liner

Das heißt, ich würde immer {} für die Programmlogik für die von anderen genannten Gründen. Wenn Sie die Klammern fallen dann ist es zu einfach, geistig stemmen, wenn er nicht da ist und subtile Code Defekte einzuführen.

Answer 20

H8ers verdammt ich bin nicht wirklich ein für dogmatische Regeln. In bestimmten Situationen werde ich bevorzugen Kompaktheit eigentlich, wenn sie nicht eine bestimmte Breite überfahren, zum Beispiel:

if(x > y)      { xIsGreaterThanY(); }
else if(y > x) { yIsGreaterThanX; }
else           { xEqualsY(); }

Das ist viel besser lesbar zu mir als:

if( x > y ){
    xIsGreaterThanY(); 
}else if( x < y){
    yIsGreaterThanX();
}else{
    xEqualsY();
}

Dies hat den zusätzlichen Vorteil der Menschen auf abstrakte Logik in Methoden zu fördern (wie ich es getan habe), anstatt zu halten mehr Logik in verschachtelten if-else-Blöcke Verklumpen. Es dauert auch ziemlich drei Linien als sieben, die es möglich machen könnten nicht mehr Methoden oder anderen Code zu haben, blättern Sie zu sehen.

Answer 21

Ich ziehe den klammert Stil, vor allem, weil sie den Augen einen klaren Start gibt und Punkt zu stoppen. Das macht es leichter zu sehen, was tatsächlich in der Erklärung enthalten ist, und dass es tatsächlich ist eine if-Anweisung. Eine kleine Sache, vielleicht, aber das ist, warum ich es verwenden.

Answer 22

so lange, wie es unter dem Team im Einklang steht Sie in dann arbeiten, um es Sache zu viel tat

, dass jeder tut das gleiche Hauptsache

Answer 23

Bracketing Ihre Einzeiler, wenn Aussagen über den erheblichen sane-Herstellung Vorteil schützt Sie so vor Kopfschmerzen haben, wenn zu einem späteren Zeitpunkt, Sie (oder andere Programmierer erhalten oder Ihren Code zu verändern) müssen Aussagen zu einem gewissen Teil dieser bedingt hinzufügen Block.

Answer 24

Wenn Sie etwas tun, wie folgt aus:

if(x)
{
    somecode;
}
else
{
    morecode;
}

Dies funktioniert besser für die Quellcodeverwaltung und Präprozessordirektiven auf Code, der lebt eine lange Zeit. Es ist einfacher, eine #if hinzuzufügen, oder so ohne versehentlich die Aussage zu brechen oder zusätzliche Zeilen mit hinzuzufügen.

Es ist ein wenig seltsam zu gewöhnen, aber ganz gut nach einem ausarbeitet während.

Answer 25

Wenn es eine Zeile if (und optional eine Zeile von anderen) Ich möchte nicht die Klammern verwenden. Es ist besser lesbar und übersichtlich. Ich sage, dass ich es vorziehen, weil es rein eine Frage der Präferenz. Obwohl ich denke, dass ein Standard zu erzwingen versuchen, dass Sie immer die geschweiften Klammern ist irgendwie albern verwenden müssen.

Wenn Sie sich Sorgen zu machen über jemanden eine andere Linie, um den Körper der if-Anweisung Hinzufügen und nicht das Hinzufügen der (nur dann erforderlich) klammern, ich glaube, Sie haben größere Probleme als Sub-byzantinisch Coding-Standards.

Answer 26

/* I type one liners with brackets like this */
if(0){return(0);}
/* If else blocks like this */
if(0){
    return(0);
}else{
    return(-1);
}

Ich verwende nie überflüssig Leerzeichen über Tabs, aber die Klammern immer inklusive spart jede Menge Zeit.

Answer 27

Ich mag nicht schließen Klammern auf die gleiche Linie mit dem Folge Stichwort:

if (x) {
    print "x is true";    
} else {
    do something else;
}

Dies macht es schwieriger / Kommentar-out entfernen nur die else-Klausel. Indem die Folge Schlüsselwort in der nächsten Zeile, ich nutzt, zum Beispiel nehmen, Editoren, die ich eine Reihe von Linien wählen lassen, und kommentieren / Kommentar- sie alle auf einmal.

if (x) {
    print "x is true";    
}
//else {
//    do something else;
//}

Answer 28

ich immer bevorzugen diese:

if (x) doSomething();

if (x) {
    doSomthing();
    doOtherthing();
}

Aber immer abhängig von der Sprache und die Aktionen, die Sie tun. Manchmal mag ich Klammern setzen und manchmal nicht. Verlassen Sie sich auf den Code, aber ich Codierung wie ein einmal zu schreiben, neu schreiben zehnmal, und hundert mal gelesen; so, tun Sie es wie Sie wollen und wie Sie lesen wollen und verstehen schneller

Answer 29

Egal was passiert, das ist die Art, wie ich gehen! Es sieht die beste.

If(x)
{
    print "Hello World !!"
}
Else
{
    print "Good bye!!"
}

Answer 30

Wenn Sie neugierig sind, was die Namen für die verschiedenen Code-Formatvorlagen sind, hat Wikipedia einen Artikel über einrücken Styles .