Marc Grabanski brachte gestern auf Twitter eine interessante Idee auf.
Kommas vor oder nach der Zeile bei JSON-Objekten und Mehrfachvariablendefinitionen?
Hier sind Beispiele für Objektliterale
// commas before
var vampyre = {
teeth: 'sharp'
, blood: 'stale'
, age: 320
}
// commas after
var vampyre = {
teeth: 'sharp',
blood: 'stale',
age: 320
}Sie sehen wahrscheinlich die meiste Zeit Kommas nach der Struktur. Es „sieht richtig aus“. Aber die Kommas davor machen diese Codeabschnitte einfacher zu handhaben.
Nehmen wir an, Sie möchten eine Zeile auskommentieren. Mit der Technik der Kommas davor kommentieren Sie die Zeile einfach aus, wie Sie es bei jeder anderen Codezeile in JavaScript tun würden, indem Sie ihr „//“ voranstellen. Bei der Struktur mit Kommas danach müssen Sie vorsichtiger sein. Wenn Sie die letzte Deklaration (Alter) auskommentieren würden, würde die letzte Deklaration mit einem Komma enden und einen Fehler auslösen. Dann bleibt Ihnen nur noch, dieses Komma manuell zu entfernen oder es ebenfalls auszukommentieren.
Es ist technisch gesehen ein Gleichstand, da das Auskommentieren aus der Mitte eines Deklarationsblocks auf beide Arten gleich ist. Kommas davor erleichtern das Auskommentieren der letzten Deklaration und Kommas danach erleichtern das Auskommentieren der ersten.
Funktioniert genauso, wenn mehrere Variablen in einer Anweisung deklariert werden
// commas before
var foo = 'bar'
, boo = 'baz'
, doo = 'dad'
;
// commas after
var foo = 'bar',
boo = 'baz',
doo = 'dad';Beachten Sie auch das Semikolon am Anfang (von Scott González). Dies trägt zur Einfachheit des Auskommentierens bei (das ist der Sinn der Sache), da Sie das Semikolon nicht auskommentieren, wenn Sie die letzte Zeile auskommentieren.
Es ist eine wirklich kleine Sache und es sieht seltsam aus, aber ich bin ein Fan der Idee mit den Kommas davor. Ich denke, es liegt daran, dass ich beim Hinzufügen neuer Deklarationen diese gerne unten hinzufüge und auf eine Weise, die beim Testen schneller und einfacher auszukommentieren ist.
Persönlich würde ich Lesbarkeit bevorzugen, daher gewinnen die Kommas danach.
Ich stimme zu. Ich bevorzuge lesbaren Code, aber ich sehe, dass Kommas davor tatsächlich besser sind.
3+ Methoden und „Kommas davor“ gewinnen bei der Testbarkeit.
Schöner Tipp. Aber das Gleiche gilt für SQL-Abfragen mit dem „AND“. Es ist wirklich einfacher, den AND-Operator an den Anfang des nächsten Satzes zu stellen.
Also
WO
klausel_1 = 1
UND klausel_2 = 2
UND klausel_3 = 3
Wenn Sie eine auskommentieren müssen, ist es so einfach
WO
klausel_1 = 1
//UND klausel_2 = 2
UND klausel_3 = 3
Diesen SQL-Trick mache ich bereits. Ich habe einfach nie daran gedacht, dasselbe mit Kommas zu tun. Toller Punkt
Aus irgendeinem Grund stimme ich zu, dass dies die bessere Art ist, SQL-Abfragen zu formatieren, und ich verwende sie selbst für SQL. Aber ästhetisch sieht die Syntax mit Kommas davor für Objektlisten schlecht aus. Was ich tue, ist implodieren für Listen, bei denen Dinge dazwischen liegen (dies gilt nur für SQL, nicht für Objekt- oder Array-Deklarationen…)
PHP
$where = array();
$where[] = "clause_1=1";
$where[] = "clause_2=2";
$where[] = "clause_3=3";
$query = "SELECT ... WHERE " . implode(" AND ", $where);
wodurch das Auskommentieren einer Zeile kinderleicht wird. Aber ich schweife ab. Das ist CSS-Tricks, keine PHP-Tricks.
Ich mag die Verwendung von implode hier wirklich, Kent! Ich hätte nie daran gedacht, es so zu verwenden. Danke fürs Kommentieren! haha
Hatte keine Gelegenheit, deine früheren Beiträge zu kommentieren..fühlte mich einfach nur, dir für deinen Videobereich auf css-tricks.com zu danken..du rockst Mann!!
Ich bin bei Darren. Während das hier gut zum Kommentieren ist, scheitert es an der Lesbarkeit, die für mich wichtiger ist.
Jedem das Seine, aber das scheint auch umständlich zu tippen zu sein.
Wow, daran habe ich noch nie gedacht, aber das ist eine großartige Idee. Wirklich gut, wenn ich beim Testen Dinge auskommentieren muss. Ich stelle heute um.
Ich mache das jetzt schon seit etwa einem Jahr. Anfangs sieht es komisch aus, aber ich kann es auf jeden Fall empfehlen. Besonders wenn Sie einen Editor haben, der Blockbearbeitung unterstützt.
Ich mag die Einfachheit des Kommentierens, und ich wurde davon schon mehrmals getroffen.
Ich halte jedoch die Lesbarkeit des Codes für viel wichtiger. Wenn der Code fertig ist, sollte er wahrscheinlich keine auskommentierten Variablen enthalten und daher so gut wie möglich lesbar sein.
Oder machen Sie es einfach wie in Python… Komma in jeder Zeile
( "etwas",
"etwas", )
Das würde nicht funktionieren.
HESDOINITRONG!
Ich sage nicht, dass Sie es können, offensichtlich ist jede Sprache anders, aber es wäre schön, oder!
„Wenn Sie die letzte Deklaration (Alter) auskommentieren würden, würde die letzte Deklaration mit einem Komma enden und einen Fehler auslösen.“
Es ist erwähnenswert, dass dies nur ein Fehler in IE6 & 7 ist. Je nach Browserunterstützung oder ob Sie nur in FF/Chrome testen, kann das letzte Komma stehen bleiben.
Und wen kümmert IE6 und IE7? ;)
Obwohl ich die Idee mag, ist mein Problem die reale Ausführung. Wenn Sie Code einrücken, sieht er tatsächlich so aus
Ich nehme an, wenn Sie Ihre Einrückungen von Hand mit Leerzeichen vornehmen, können Sie das Aussehen erzielen, das Sie in Ihrem Beispiel verwenden. Aber dann geht die gesamte Zeit, die Sie durch das Nicht-Auskommentieren von Mehrzeilen-Kommentaren gespart haben, verloren.
Ganz zu schweigen davon, dass in den meisten vernünftigen Code-Editoren das Auskommentieren von Code (egal ob eine Zeile oder mehrere) so einfach ist wie das Markieren des Codeblocks und das Drücken einer Tastenkombination.
Ich mache normalerweise Kommas danach, aber die Sache mit den Kommas davor ist sehr interessant und ich denke, ich werde es beim nächsten Mal ausprobieren. Danke, Chris!
Abstände wurden nicht übertragen, aber ich denke, Sie verstehen, was gemeint ist.
Das lässt mich fragen, ob CSS-Semikolons auf die gleiche Weise behandelt werden könnten.
Ich bin auch ein großer Fan der Kommas-vor-Syntax!
Allerdings lasse ich eine Zeile mehr nach dem Wort var (oder der öffnenden Klammer) weg, und das Semikolon (oder die schließende Klammer) steht am Anfang der Zeile.
Ich versuche, jeden Anfang und jedes Ende einer Anweisung auf eine eigene Zeile zu setzen (dasselbe gilt für JS, TSQL, PowerScript…).
Es hat mich ein paar Mal gedauert, diese Syntax zu schätzen, aber ich mag sie jetzt WIRKLICH.
Kommas davor sind nicht nur praktisch zum Auskommentieren, sondern erleichtern auch das Hinzufügen neuer Zeilen durch Kopieren/Einfügen der letzten Zeile.
Hilft das wirklich beim Kommentieren?
Was ist, wenn ich „teeth: ‚sharp'“ auskommentiere… haben wir nicht gerade das Problem vom „Problem beim Auskommentieren des letzten Elements“ auf ein „Problem beim Auskommentieren des ersten Elements“ verschoben?
Korrekt.
Zitat
Ist beim Kommentieren nicht beides gleich?
Wenn Sie die erste Zeile auskommentieren, bricht der Code auch?
Ich habe diesen Ansatz verwendet, aber glücklicherweise haben meine Kollegen mich davon überzeugt. Allein die Tatsache, dass diese Formatierung Fehler in jslint auslöst, war für mich Grund genug, sie aufzugeben.
Erstens, ich **liebe** es, dass Sie darüber geschrieben haben, denn dies ist eines dieser Stilfragen, die jedem, der für das Web programmiert, am Herzen liegen.
Zweitens, für die PHP-Programmierer unter Ihnen: Sie haben es richtig gemacht und erlauben einen nachgestellten Schrägstrich in Array-Deklarationen, was eine erstaunliche Wahl ist, die das Leben für diejenigen, die sie ausnutzen, einfacher macht
$a = array(
"Orangen",
"Äpfel",
"Zitronen",
);
Ich neige dazu zuzustimmen, dass es das Problem einfach vom Anfang der Liste zum Ende der Liste verlagert. Ich bevorzuge die Kommas danach, weil sie einfach besser aussehen.
Außerdem, verwenden Sie jslint und testen Sie Ihren JavaScript-Code, und die anderen Nachteile werden akademisch.
Meiner bescheidenen Meinung nach.
Da Kommas davor keine wirklichen Vorteile bringen, denke ich, man sollte die Konvention, wenn auch eine weiche Konvention, der persönlichen Vorliebe vorziehen. Es geht nicht darum, was *Sie* bevorzugen, sondern hauptsächlich um die Lesbarkeit für andere.
Interessante Idee, aber ich wähle Lesbarkeit ftw. Das Gute scheint die Nachteile nicht aufzuwiegen, besonders da man irgendwie immer noch das gleiche Problem hat.. vielleicht nur etwas seltener :/ interessante Idee aber!
Ich gehe voll und ganz auf Lesbarkeit. Ich habe festgestellt, dass schlecht strukturierter Code in einer Teamumgebung schlechter ist, weil es mehr Zeit braucht, um herauszufinden, was Sie tun wollen, als etwas auszukommentieren.
Dieser Artikel von inimino argumentiert gut für Kommas-zuerst: http://inimino.org/~inimino/blog/javascript_whitespace
Ich benutze heutzutage immer Kommas davor, besonders bei Explorer, das einen Aufstand macht, wenn man ein zusätzliches Komma hinterlässt -> leicht zu machen, wenn man viel Jquery-Code schreibt. Ich finde auch, dass Kommas davor beim Schreiben komplexer MySQL-Abfragen zu weniger Fehlern führt.
Ich hasse es, wenn Leute den Kommas-davor-Trick machen. Es sieht einfach falsch aus. Ist es wirklich so schwer, einfach noch einmal zu überprüfen, ob man ein Komma nicht übersprungen hat?
Ich mag den Kommas-davor-Trick nicht. Es scheint, der einzige Vorteil ist, dass man leichter etwas auskommentieren kann, auf Kosten des Verlusts der Lesbarkeit. Wie das Zen von Python sagt: „Lesbarkeit zählt“. Außerdem schadet ein nachgestelltes Komma in vielen anderen Sprachen nicht. Wenn Sie gleichzeitig eine dieser Sprachen verwenden, wird es schwierig sein, im Kommas-davor-Stil nur in JavaScript zu wechseln.
Lesbarkeit steht immer an erster Stelle (meiner Meinung nach). Also ist meine Wahl „Kommas danach“.
Was SQL-Abfragen betrifft, schreibe ich sowohl „AND davor“ als auch „AND danach“-Anweisungen, aber häufiger verwende ich „AND davor“.
Der Grund ist, dass „AND“/„OR“-Wörter in Abfragen viel aussagekräftiger sind als Kommas in Arrays oder anderen Listen.
Kommas sind nur die Trennzeichen, und der Grund, sie davor oder danach zu setzen, ist nur die Gewohnheit, Kommentare zu platzieren/neue Zeilen vor der ersten Zeile oder nach der letzten einzufügen.
Im Gegensatz dazu: SQL-Wörter spielen eine große Rolle für die Logik und sollten sichtbar sein. Deshalb halte ich es für besser, sie an erster Stelle des Strings zu setzen.
Hä? Es ist nicht die Position der Kommas, die beim Kommentieren hilft, sondern die Verwendung von neuen Zeilen.
Großartiger Artikel zu Kommas davor, habe ich mir vorher noch nicht wirklich Gedanken darüber gemacht, aber einige großartige Punkte, ich bevorzuge aber wirklich die Lesbarkeit. LT
Cooler Artikel Mann! Ich lese gerne deine Posts.
Ich würde mich für danach entscheiden, keine Fragen, es sieht einfach richtig aus :)
Interessanter Punkt.
Ich mache das immer, wenn ich SQL-Befehle schreibe, was ich in letzter Zeit viel tue. Es macht alles viel lesbarer.
Habe das auch viel mit SQL-Syntax gemacht. Für das funktioniert es gut. Aber jetzt bevorzuge ich die Kommas-danach-Methode, einfach weil sie für die meisten Codes besser aussieht. Ich schätze, es ist eine Frage der Präferenz, und es kann davon abhängen, wie oft Sie Kommentare für jede Zeile ein- und ausschalten müssen.
Für mich sind beide gut. Ich benutze sie je nach Codeanforderung. Persönlich macht es mehr Sinn, die Kommas am Ende zu setzen und zu bedenken, dass Sie nicht der Einzige sind, der an einer Anwendung arbeitet, es könnten andere mit Ihnen arbeiten…. :)
Nun, ich muss sagen, Kommas zuerst ist der Vokuhila von JavaScript: Kommas vorne, Party hinten!
Ich mag Kommas davor in der Theorie, habe es aber noch nicht in die Praxis umgesetzt und werde es wahrscheinlich auch nie tun. Es gibt den Faktor „es sieht seltsam aus“ und dann die Lesbarkeit für die Entwickler, die nach mir am Code arbeiten. Der Vorteil ist, dass es mir bei meinem Problem mit den nachgestellten Kommas helfen würde.
Absolut Kommas danach. Lesbarkeit ist mir viel wichtiger, als es ein bisschen einfacher zu kommentieren. Der beste Code braucht keine Kommentare ;)
Ruby erlaubt Ihnen Kommas auch am Ende der Anweisung!
Danach.. Aber ich kann sehen, wie davor auch funktionieren könnte. Danke für den tollen Beitrag!
kann ich es auf einer Zeile tippen wie
var vampyre = {teeth: ‘sharp’, blood: ‘stale’ , age: 320}
Ich bin etwas spät dran, aber ich muss sagen, ich bin vom Kommas-davor-Ansatz fasziniert. Die Vorteile beim Kommentieren sind hinfällig, aber ich weiß, dass Kommas davor mir viel Zeit beim Finden von Syntaxfehlern in JavaScript erspart hätten, die ich in der Vergangenheit geschrieben habe. Geradlinige Kommas davor? Gut. Nein? Muss das korrigiert werden.
Ich muss den Kommentaren „Lesbarkeit FTW/es sieht komisch aus“ widersprechen. Es ist einfach eine Frage dessen, was Sie gewohnt sind zu sehen. Code damit für ein paar Wochen und Sie werden sich daran gewöhnen. Außerdem ist JSLint konfigurierbar.
Ich habe nie darüber nachgedacht, habe immer Kommas danach verwendet, aber es scheint, dass Kommas davor leicht zu lesen sind und sie in vielen Fällen herausstechen, in denen wir Kommas danach oft übersehen.
Danke für die Kommas davor