javascript funktionen - Sind geschweifte Klammern in einzeiligen Anweisungen in JavaScript erforderlich?




9 Answers

Nein

Aber sie werden empfohlen. Wenn Sie die Anweisung erweitern, benötigen Sie sie.

Dies ist absolut gültig

if (cond) 
    alert("Condition met!")
else
    alert("Condition not met!")

Es wird jedoch dringend empfohlen, immer geschweifte Klammern zu verwenden, denn wenn Sie (oder eine andere Person) die Anweisung jemals erweitern, wird sie benötigt.

Dieselbe Praxis folgt in allen C-Syntax-Stilsprachen mit Bracing. C, C ++, Java, sogar PHP unterstützen alle eine Zeilenanweisung ohne Klammern. Sie müssen sich darüber im Klaren sein, dass Sie nur zwei Zeichen speichern und mit einigen Bracing Styles sparen Sie nicht einmal eine Zeile. Ich bevorzuge einen vollen Brace-Stil (wie folgt), also neigt es dazu, ein bisschen länger zu sein. Der Kompromiss ist sehr gut mit der Tatsache erfüllt, dass Sie eine extrem klare Code-Lesbarkeit haben.

if (cond) 
{
    alert("Condition met!")
}
else
{
    alert("Condition not met!")
}
aufrufen typescript

Ich habe einmal gehört, dass das Verlassen der geschweiften Klammern in einzeiligen Anweisungen in JavaScript schädlich sein könnte. Ich erinnere mich nicht mehr an die Argumentation und eine Google-Suche half nicht viel. Gibt es etwas, das es gut macht, alle Anweisungen in geschweiften Klammern in JavaScript zu umgeben?

Ich frage, weil jeder scheint so zu tun.




Die Frage fragt nach Aussagen in einer Zeile. Die vielen Beispiele zeigen jedoch, dass Klammern aufgrund von mehrzeiligen Anweisungen nicht weggelassen werden sollten. Es ist absolut sicher, keine Klammern in einer Zeile zu verwenden, wenn dies der bevorzugte Codierungsstil ist.

Zum Beispiel fragt die Frage, ob das in Ordnung ist:

 if (condition) statement;

Es fragt nicht, ob das in Ordnung ist:

 if (condition)
   statement;

Ich denke, Klammern zu verlassen ist vorzuziehen, weil es den Code mit weniger überflüssiger Syntax lesbarer macht.

Mein Codierungsstil besteht darin, niemals Klammern zu verwenden, es sei denn, der Code ist ein Block. Und niemals mehrere Anweisungen in einer einzigen Zeile (getrennt durch Semikolons) zu verwenden. Ich finde das leicht zu lesen und klar und habe nie Skoping-Probleme bei "if" -Aussagen. Daher benötigt die Verwendung von Klammern in einer einzigen if-Bedingungsanweisung 3 Zeilen. So was:

 if (condition) {
   statement;
 }

Die Verwendung einer If-Anweisung mit einer Zeile ist vorzuziehen, da weniger vertikaler Platz benötigt wird und der Code kompakter ist.

Ich würde andere nicht zwingen, diese Methode zu verwenden, aber es funktioniert für mich, und ich konnte den Beispielen nicht mehr widersprechen, wie das Auslassen von Klammern zu Codierungs- / Bereichsfehlern führt.




Neben dem von @Josh K genannten Grund (der auch für Java, C usw. gilt), ist ein spezielles Problem in JavaScript das automatische Einfügen von Semikolons . Aus dem Wikipedia-Beispiel:

return
a + b;

// Returns undefined. Treated as:
//   return;
//   a + b;

Dies kann auch zu unerwarteten Ergebnissen führen, wenn es wie folgt verwendet wird:

if (x)
   return
   a + b;

Es ist nicht wirklich viel besser zu schreiben

if (x) {
   return
   a + b;
}

aber vielleicht ist der Fehler hier ein wenig leichter zu erkennen (?)




Absolut ja

Vergessen Sie "Es ist persönliche Präferenz", "der Code wird gut laufen", "es hat gut für mich gearbeitet", "es ist lesbarer" yada yada BS.

Argument: "Es ist persönliche Vorliebe"

Nein ist es nicht. Es sei denn, du bist ein Ein-Mann-Team, das auf dem Mars geht, nein. Die meiste Zeit wird es andere Leute geben, die Ihren Code lesen / ändern. In jedem seriösen Coding-Team wird dies der empfohlene Weg sein, also ist es keine "persönliche Präferenz".

Argument: "Der Code wird gut laufen"

So auch der Spaghetti-Code! Bedeutet es, dass es in Ordnung ist, es zu erstellen?

Argument: "Es hat gut für mich gearbeitet"

In meiner Karriere habe ich so viele Fehler gesehen, die wegen dieses Problems entstanden sind. Du erinnerst dich wahrscheinlich nicht daran, wie oft du 'DoSomething()' und warum 'SomethingElse()' heißt:

if (condition) 
    DoSomething();
SomethingElse();

Oder "SomethemMore" hinzugefügt und nicht bemerkt, dass es nicht aufgerufen wird (obwohl der Einzug etwas anderes bedeutet):

if (condition)
  DoSomething();
  SomethingMore();

Hier ist ein Beispiel aus dem wirklichen Leben, das ich hatte. Jemand wollte die gesamte Protokollierung //"Console.println" so dass sie "Console.println" => //"Console.println" "Console.println" finden und ersetzen.

if (condition) 
   Console.println("something");
SomethingElse();

Siehst du das Problem?

Selbst wenn du denkst, "diese sind so trivial, würde ich das nie tun"; Denke daran, dass es immer ein Teammitglied mit schlechteren Programmierkenntnissen als du geben wird (hoffentlich bist du nicht das Schlechteste im Team!)

Argument: "Es ist lesbarer"

Wenn ich etwas über Programmierung gelernt habe, dann werden die einfachen Dinge sehr schnell sehr komplex. Es ist sehr üblich, dass dies:

if (condition) 
    DoSomething();

verwandelt sich in das Folgende, nachdem es mit verschiedenen Browsern / Umgebungen / Anwendungsfällen getestet wurde oder neue Funktionen hinzugefügt wurden:

if (a != null)
   if (condition) 
      DoSomething();
   else
      DoSomethingElse(); 
      DoSomethingMore();
else 
    if (b == null)
         alert("error b");
    else 
         alert("error a");

Und vergleichen Sie es damit:

 if (a != null) {
    if (condition) { 
       DoSomething();
    }
    else {
       DoSomethingElse();
       DoSomethingMore();
    }
 } else if (b == null) {
    alert("error b");
 } else {
    alert("error a");
 }

PS: Bonuspunkte gehen an diejenigen, die den Bug im obigen Beispiel bemerkt haben




Hier ist, warum es empfohlen wird

Sagen wir, ich schreibe

if(someVal)
    alert("True");

Dann kommt der nächste Entwickler und sagt "Oh, ich muss etwas anderes machen", also schreiben sie

if(someVal)
    alert("True");
    alert("AlsoTrue");

Wie Sie sehen können, wird "AlsoTrue" immer korrekt sein, da der erste Entwickler keine Klammern verwendet hat.




Manchmal scheinen sie gebraucht zu werden! Ich konnte es selbst nicht glauben, aber gestern kam es mir in einer Firebug-Session (neuer Firefox 22.0) so vor

if (! my.condition.key)
    do something;

ausgeführt etwas trotz my.condition.key war wahr . Klammern hinzufügen:

if (! my.condition.var) {
    do something;
}

reparierte diese Angelegenheit. Es gibt unzählige Beispiele, wo es scheinbar ohne die Zahnspange funktioniert, aber in diesem Fall hat es das definitiv nicht getan.

Leute, die dazu neigen, mehr als eine Aussage in eine Zeile zu schreiben, sollten natürlich immer Klammern verwenden, natürlich, weil Dinge wie

if (condition)
    do something; do something else;

sind schwer zu finden.




Es gibt viele Probleme in Javascript. Sehen Sie sich den JavaScript-Architekten Douglas Crockford an, der darüber spricht. Die if- Anweisung scheint in Ordnung zu sein, aber die return- Anweisung kann ein Problem verursachen.

return
{
    ok:false;
}
//silent error (return undefined)

return{
    ok:true;
}
//works well in javascript



Ich fand diese Antwort auf der Suche nach einer ähnlichen Erfahrung, also entschied ich mich, sie mit meiner Erfahrung zu beantworten.

Bracketless-Anweisungen funktionieren in den meisten Browsern. Ich habe jedoch getestet, dass eckige Methoden in einem Browser nicht funktionieren.

Ab dem 26. Februar 2018 funktioniert diese Aussage in Pale Moon, aber nicht in Google Chrome.

function foo()
   return bar;



Das habe ich immer gefunden

if(valid) return;

ist leichter für mein Auge als

if(valid) {
  return;
}

auch bedingte wie

(valid) ? ifTrue() : ifFalse();

sind leichter zu lesen (meine persönliche Meinung) als

if(valid) {
  ifTrue();
} else {
  ifFalse();
}

aber ich denke, es kommt auf Coding-Stil




Related

javascript

Tags

javascript