javascript - klammern - typescript datentypen




Sind geschweifte Klammern in einzeiligen Anweisungen in JavaScript erforderlich? (12)

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.


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!")
}

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


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.


Es gibt eine Möglichkeit, mehrere Zeilen nicht geschweifte Klammern zu erreichen, wenn Anweisungen ... (Wow was Englisch ..) aber es ist irgendwie Tedius:

if(true)
   funcName();
else
   return null;


function funcName(){
  //Do Stuff Here...
}

Es gibt kein Wartbarkeitsproblem!

Das Problem mit euch allen ist, dass Sie überall Semikolons setzen. Sie benötigen keine geschweiften Klammern für mehrere Anweisungen. Wenn Sie eine Anweisung hinzufügen möchten, verwenden Sie einfach Kommas.

if (a > 1)
 alert("foo"),
 alert("bar"),
 alert("lorem"),
 alert("ipsum");
else
 alert("blah");

Dies ist ein gültiger Code, der so läuft, wie Sie es erwarten!


Es gibt keinen Programmiergrund, die geschweiften Klammern in Anweisungen mit einer Zeile zu verwenden.

Dies kommt nur auf die Vorlieben und Lesbarkeit der Programmierer zurück.

Dein Code wird deswegen nicht brechen.


Es ist eine Frage des Stils, aber geschweifte Klammern sind gut, um zu verhindern, dass andere baumeln .


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.


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;

Ich möchte nur darauf hinweisen, dass Sie die geschweiften Klammern auch nur von den anderen Klammern entfernen können. Wie in diesem Artikel von John Resig gesehen .

if(2 == 1){
    if(1 == 2){
        console.log("We will never get here")
    }
} else 
    console.log("We will get here")

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





javascript