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




aufrufen typescript (15)

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

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.


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.


Ich arbeite gerade an einem Minifier. Sogar jetzt überprüfe ich es auf zwei riesigen Skripten. Experimentell fand ich heraus: Sie können die geschweiften Klammern hinter für, wenn, sonst, while Funktion entfernen, wenn die geschweiften Klammern ';', 'Rückkehr', 'für', 'wenn', 'sonst', 'während', 'tun', 'funktionieren'. Unabhangige Zeilenumbrüche.

function a(b){if(c){d}else{e}} //ok  
function a(b){if(c)d;else e}   //ok

Natürlich müssen Sie die schließende Klammer durch ein Semikolon ersetzen, wenn nicht an einer anderen schließenden Klammer gefolgt wird.

Eine Funktion darf nicht in einem Komma enden.

var a,b=function()c;  //ok *but not in Chrome
var b=function()c,a;  //error  

Getestet auf Chrome und FF.


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.


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

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 (?)


Die Anfangseinrückungsstufe einer Anweisung sollte der Anzahl der darüber liegenden offenen Klammern entsprechen. (ohne zitierte oder kommentierte Klammern oder solche in Präprozessordirektiven)

Ansonsten wäre K & R ein guter Eindrucks-Stil. Um ihren Stil zu korrigieren, empfehle ich, kurze einfache if-Anweisungen in einer Zeile zu platzieren.

if (foo) bar();    // I like this. It's also consistent with Python FWIW

Anstatt von

if (foo)
   bar();   // not so good

Wenn ich einen Editor schreiben würde, würde ich den Auto-Format-Button dazu bringen, die Leiste bis zur selben Zeile wie foo anzusaugen, und ich würde Klammern um den Balken einfügen, wenn du Return drückst, bevor es so aussieht:

if (foo) {
  bar();    // better
}

Dann ist es einfach und konsistent, neue Anweisungen oberhalb oder unterhalb von Balken innerhalb des Körpers der if-Anweisung hinzuzufügen

if (foo) {
  bar();    // consistent
  baz();    // easy to read and maintain
}

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;


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...
}

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

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 einen Aspekt der Lesbarkeit - wenn Sie zusammengesetzte Anweisungen haben, kann das sehr verwirrend werden. (Einrücken hilft, bedeutet aber für den Compiler / Interpreter nichts)

var a;
var b;
var c;

//Indenting is clear
if (a===true)
  alert(a); //On on IF
alert(b); //Always

//Indenting is bad
if (a===true)
  alert(a); //On on IF
  alert(b); //Always but expected?

//Nested indenting is clear
if (a===true)
  if (b===true)
    alert(a); //Only on if-if
alert (b); //Always

//Nested indenting is misleading
if (a===true)
  if (b===true)
    alert(a); //Only on if-if
  alert (b); //Always but expected as part of first if?

//Compound line is misleading
//b will always alert, but suggests it's part of if
if (a===true) alert(a);alert(b); 
else alert(c); //Error, else isn't attached

Und dann gibt es einen Erweiterbarkeitsaspekt:

//Problematic
if (a===true)
  alert(a);
  alert(b); //We're assuming this will happen with the if but it'll happen always
else       //This else is not connected to an if anymore - error
  alert(c);

//Obvious
if (a===true) {
  alert(a); //on if
  alert(b); //on if
} else {
  alert(c); //on !if
} 

(Wenn Sie immer die Klammern haben, wissen Sie, dass Sie andere Anweisungen in diesen Block einfügen).


John Resig hat eine gute Implementierung gepostet :

// Array Remove - By John Resig (MIT Licensed)
Array.prototype.remove = function(from, to) {
  var rest = this.slice((to || from) + 1 || this.length);
  this.length = from < 0 ? this.length + from : from;
  return this.push.apply(this, rest);
};

Wenn Sie ein globales Objekt nicht erweitern möchten, können Sie stattdessen Folgendes tun:

// Array Remove - By John Resig (MIT Licensed)
Array.remove = function(array, from, to) {
    var rest = array.slice((to || from) + 1 || array.length);
    array.length = from < 0 ? array.length + from : from;
    return array.push.apply(array, rest);
};

Der Hauptgrund, warum ich dies poste, ist, Benutzer vor der alternativen Implementierung zu warnen, die in den Kommentaren auf dieser Seite (14. Dezember 2007) vorgeschlagen wird:

Array.prototype.remove = function(from, to){
  this.splice(from, (to=[0,from||1,++to-from][arguments.length])<0?this.length+to:to);
  return this.length;
};

Es scheint anfangs gut zu funktionieren, aber durch einen schmerzhaften Prozess habe ich festgestellt, dass es fehlschlägt, wenn versucht wird, das vorletzte Element in einem Array zu entfernen. Wenn Sie beispielsweise ein Array mit 10 Elementen haben und versuchen, das 9. Element folgendermaßen zu entfernen:

myArray.remove(8);

Sie erhalten ein 8-Element-Array. Ich weiß nicht warum, aber ich habe bestätigt, dass Johns ursprüngliche Implementierung dieses Problem nicht hat.





javascript