Was ist der bevorzugte Stil für einzelne Entscheidungs- und Handlungsanweisungen?

Question

Im Fall von Sprachen, die einzelne Entscheidungen und Aktionen ohne Klammern unterstützen, wie im folgenden Beispiel:

if (var == true)
    doSomething();

Wie schreibe ich das am liebsten?Sollten immer Klammern verwendet werden oder sollte ihre Verwendung dem individuellen Entwickler überlassen werden?Hängt diese Vorgehensweise außerdem von der Größe des Codeblocks ab, wie im folgenden Beispiel:

if (var == 1)
    doSomething(1);
else if (var > 1 && var < 10)
    doSomething(2);
else
{
    validate(var);
    doSomething(var);
}

Answer 1

Es gibt nicht wirklich eine richtige Antwort.Dafür gibt es Kodierungsstandards im Unternehmen.Wenn Sie es im gesamten Unternehmen einheitlich halten können, ist es leicht lesbar.Mir persönlich gefällt es

if ( a == b)    {
    doSomething();
}
else {
    doSomething();
}

aber das ist ein heiliger Krieg.

Answer 2

Ich empfehle

if(a==b)
{
    doSomething();
}

weil ich es viel einfacher finde, es im Voraus zu tun, als zu versuchen, daran zu denken, die geschweiften Klammern hinzuzufügen, wenn ich der Erfolgsbedingung eine zweite Anweisung hinzufüge ...

if(a==b)
    doSomething();
    doSomethingElse();

ist ganz anders als

if(a==b)
{
    doSomething();
    doSomethingElse();
}

sehen Joels Artikel für weitere Details

Answer 3

Ich neige dazu, immer eine Zahnspange zu verwenden.Sie können einige subtile Fehler bekommen, wenn Sie mit so etwas angefangen haben:

if(something)
 DoOneThing();
else
  DoItDifferently();

und entscheiden Sie sich dann, dem eine weitere Operation hinzuzufügen else Klausel und vergessen Sie, sie in geschweifte Klammern zu setzen:

if(something)
 DoOneThing();
else
  DoItDifferently();
  AlwaysGetsCalled(); 

AlwaysGetsCalled() wird immer aufgerufen, und wenn Sie um 3 Uhr morgens da sitzen und sich fragen, warum sich Ihr Code so seltsam verhält, könnte Ihnen so etwas eine ganze Weile entgehen.Allein aus diesem Grund verwende ich immer eine Zahnspange.

Answer 4

Ich bevorzuge Konsistenz. Wenn Sie beispielsweise Klammern in einem Block verwenden, verwenden Sie überall Klammern, auch bei nur einer Anweisung:

if (cond1)
{
   SomeOperation();
   Another();
}
elseif (cond2)
{
   DoSomething();
}
else
{
   DoNothing();
   DoAnother();
}

Aber wenn Sie nur ein paar Einzeiler haben:

if (cond1)
    DoFirst();
elseif (cond2)
    DoSecond();
else
    DoElse();

Sieht auf diese Weise sauberer aus (wenn Ihnen die Dummy-Methodennamen nichts ausmachen ;), aber das ist nur meine Meinung.

Dies gilt auch für Schleifenkonstrukte und dergleichen:

foreach (var s as Something)
    if (s == someCondition)
        yield return SomeMethod(s);

Sie sollten auch bedenken, dass dies eine Konvention ist, die möglicherweise besser für .NET geeignet ist (beachten Sie, dass Java-Peepz ihre erste geschweifte Klammer gerne in derselben Zeile wie das If haben).

Answer 5

Man kann dies auf mangelnde Erfahrung zurückführen, aber während meiner siebenjährigen Tätigkeit als Code-Affe habe ich das getan niemals Ich habe tatsächlich gesehen, dass jemand den Fehler gemacht hat, keine geschweiften Klammern hinzuzufügen, wenn er Code zu einem Block hinzufügt, der keine geschweiften Klammern hat.Das ist genau null mal.

Und bevor die Witzbolde gleich dazu kommen: Nein, der Grund war nicht „jeder trägt immer eine Zahnspange“.

Also eine ehrliche Frage – ich würde wirklich gerne tatsächliche Antworten erhalten, anstatt nur negative Stimmen:kommt das überhaupt jemals vor?

(Bearbeiten:Ich habe genug Outsourcing-Horrorgeschichten gehört, um es ein wenig klarzustellen:Passiert das überhaupt jemals? kompetente Programmierer?)

Answer 6

Es spielt keine Rolle, solange man damit konsequent ist.

Es scheint eine Tendenz zu geben, Gleichheit innerhalb einer einzelnen Aussage zu fordern, d. h.Wenn es in einem Zweig Klammern gibt, gibt es überall Klammern.Zum einen schreiben die Linux-Kernel-Codierungsstandards dies vor.

Answer 7

Ich würde es energisch befürworten stets Verwenden von geschweiften Klammern, auch wenn diese optional sind.Warum?Nehmen Sie diesen Teil des C++-Codes:

if (var == 1)
  doSomething();
doSomethingElse();

Nun kommt jemand vorbei, der nicht wirklich genug aufpasst und beschließt, dass etwas Besonderes passieren muss, wenn (var == 1), also macht er Folgendes:

if (var == 1)
  doSomething();
  doSomethingExtra();
doSomethingElse();

Es ist alles immer noch schön eingerückt, aber es erfüllt nicht das, was beabsichtigt war.

Wenn Sie immer geschweifte Klammern verwenden, ist es wahrscheinlicher, dass Sie Fehler dieser Art vermeiden.

Answer 8

Ich persönlich schließe mich McConnells Erklärung aus Code Complete an.

Nutzen Sie sie, wann immer Sie können.Sie verbessern die Lesbarkeit Ihres Codes und beseitigen die wenigen und seltenen Verwirrungen, die auftreten könnten.

Eines ist jedoch wichtiger: Konsistenz.Welchen Stil Sie auch immer verwenden, stellen Sie sicher, dass Sie ihn immer auf die gleiche Weise anwenden.

Fangen Sie an, Dinge zu schreiben wie:

If A == true
   FunctA();

If B == "Test"
{
   FunctB();
}

Am Ende werden Sie bestimmt nach einem seltsamen Fehler suchen, bei dem der Compiler nicht versteht, was Sie tun wollten, und der schwer zu finden sein wird.

Finden Sie im Grunde immer diejenige, die Sie gerne schreiben, und bleiben Sie dabei.Ich glaube, dass es der richtige Weg ist, die Blocktrennzeichen ('{', '}') so oft wie möglich zu verwenden.

Ich möchte nicht eine Frage in einer anderen beginnen, aber es gibt etwas, das damit zusammenhängt und das ich erwähnen möchte, um Sie geistig in Schwung zu bringen.Zum einen ist die Entscheidung für die Verwendung der Klammern gefallen.Wo platzierst du die öffnende Klammer?In derselben Zeile wie die Anweisung oder darunter.Eingerückte Klammern oder nicht?

If A == false {
  //calls and whatnot
}
//or
If B == "BlaBla"
{
  //calls and whatnot
}
//or
If C == B
  {
  //calls and whatnot
  }

Bitte antworten Sie nicht darauf, da dies eine neue Frage wäre.Wenn ich Interesse daran sehe, werde ich eine neue Frage zu Ihrem Beitrag eröffnen.

Answer 9

Ich habe immer immer Klammern verwendet, außer in dem Fall, dass ich eine Variable auf NULL überprüfe, bevor ich sie freigebe, wie es in C notwendig ist

In diesem Fall stelle ich sicher, dass klar ist, dass es sich um eine einzige Aussage handelt, indem ich alles in einer Zeile halte, etwa so:

if (aString) free(aString);

Answer 10

Es gibt keine richtige oder falsche Art, die obige Aussage zu schreiben.Es gibt viele akzeptierte Codierungen Stile.Allerdings bevorzuge ich es, den Codierungsstil während des gesamten Projekts beizubehalten.dh.Wenn das Projekt den K&R-Stil verwendet, sollten Sie K&R verwenden.

Answer 11

Ruby räumt ein Problem in der Diskussion gut aus dem Weg.Der Standard für einen Einzeiler ist:

do_something if (a == b)

und für eine Mehrzeile:

if (a == b)
  do_something
  do_something_else
end

Dies ermöglicht prägnante einzeilige Anweisungen, zwingt Sie jedoch dazu, die Anweisung neu zu organisieren, wenn Sie von einzeiligen zu mehrzeiligen Anweisungen wechseln.

Dies ist (noch) nicht in Java und auch nicht in vielen anderen Sprachen verfügbar, AFAIK.

Answer 12

Wie andere bereits erwähnt haben, kann die Ausführung einer if-Anweisung in zwei Zeilen ohne geschweifte Klammern zu Verwirrung führen:

if (a == b)
    DoSomething();
    DoSomethingElse(); <-- outside if statement

Deshalb platziere ich es in einer einzelnen Zeile, wenn ich dies ohne Beeinträchtigung der Lesbarkeit tun kann:

if (a == b) DoSomething();

und zu allen anderen Zeiten verwende ich Zahnspangen.

Ternäre Operatoren sind etwas anders.Meistens mache ich sie in einer Zeile:

var c = (a == b) ? DoSomething() : DoSomethingElse();

Aber manchmal haben die Aussagen verschachtelte Funktionsaufrufe oder Lambda-Ausdrücke, die eine Einzeilenanweisung schwierig machen, visuell zu analysieren, daher bevorzuge ich so etwas:

var c = (a == b)
    ? AReallyReallyLongFunctionName()
    : AnotherReallyReallyLongFunctionOrStatement();

Immer noch prägnanter als ein if/else-Block, aber leicht zu erkennen, was vor sich geht.

Answer 13

Sun's Codekonventionen für die Programmiersprache Java hat Das sagen:

Die IF-ELSE-Klasse von Aussagen sollte das folgende Formular haben:

if (condition) {
    statements;
}

if (condition) {
    statements;
} else {
    statements;
}

if (condition) {
    statements;
} else if (condition) {
    statements;
} else {
    statements;
}

Answer 14

Unser Chef lässt uns { } hinter eine Entscheidungsaussage setzen, egal was passiert, auch wenn es sich um eine einzelne Aussage handelt.Es ist wirklich ärgerlich, zwei zusätzliche Zeilen hinzuzufügen.Die einzige Ausnahme bilden ternäre Operatoren.

Ich denke, es ist gut, dass ich meinen Codemonitor im Hochformat bei 1200 x 1600 habe.

Answer 15

ich bevorzuge

if (cond)
   {
   //statement
   }

auch mit nur einer einzigen Aussage.Wenn Sie schon einmal etwas schreiben wollten, keinen Zweifel daran hatten, dass es funktioniert, und nie geplant haben, dass sich jemals ein anderer Programmierer diesen Code ansieht, verwenden Sie einfach das gewünschte Format.Aber was kostet Sie die zusätzliche Belichtungsreihe wirklich?Im Laufe eines Jahres dauert es weniger Zeit, als für das Verfassen dieses Beitrags erforderlich ist.

Ja, ich möchte meine Klammern auch gerne auf Blockebene einrücken.

Das Schöne an Python ist, dass die Einrückung den Block definiert.Die Frage ist in einer solchen Sprache strittig.

Answer 16

Ich tendiere dazu, Joel Spolsky in diesem Artikel zuzustimmen (Falschen Code falsch aussehen lassen) mit dem folgenden Codebeispiel:

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

Foo ist jetzt bedingungslos.Was wirklich schlecht ist!

Ich verwende bei Entscheidungsaussagen immer Klammern.Es erleichtert die Wartbarkeit des Codes und macht den Code weniger fehleranfällig.

Answer 17

Ich verwende geschweifte Klammern um jede Aussage, wenn und nur dann, wenn mindestens eine davon dies erfordert.

Answer 18

Wenn Sie in Perl einen einfachen Test durchführen, schreiben Sie ihn manchmal in dieser Form:

do_something if condition;

do_something unless condition;

Dies kann sehr nützlich sein, um die Argumente am Anfang einer Unterroutine zu überprüfen.

sub test{
  my($self,@args) = @_;

  return undef unless defined $self;

  # rest of code goes here

}

Answer 19

Die goldene Regel lautet, dass Sie bei der Arbeit an einem bestehenden Projekt diese Codierungsstandards befolgen sollten.

Wenn ich zu Hause bin, habe ich zwei Formen.

Die erste ist die einzelne Zeile:

if (condition) doThis();

und die zweite ist für mehrere Zeilen:

if (condition) {
   doThis();
}

Answer 20

Früher folgte ich wie ein Apparatschik der Regel „Immer geschweifte Klammern verwenden“.Allerdings habe ich meinen Stil geändert, um sie in einzeiligen bedingten Ausdrücken wegzulassen:

if(!ok)return;

Für jedes Szenario mit mehreren Anweisungen bin ich jedoch immer noch der Meinung, dass geschweifte Klammern obligatorisch sein sollten:

if(!ok){

    do();

    that();

    thing();
}