Js-beautify: Unterstützen Sie den Komma-ersten Stil der Variablendeklaration

Da wir sowohl JS als auch Python unterstützen, ist der Patch (der stark veraltet ist) bestenfalls unvollständig.

Wir sind offen für Pull-Requests, aber ich persönlich halte "Comma-First" für ein Anti-Pattern. Im Kern ist js-beautifier rechthaberisch darüber, wie JS aussehen sollte, mit vernünftigen Optionen, die weitgehend dem weithin akzeptierten "idiomatischen" JS entsprechen. Komma-zuerst ist meiner Meinung nach weder schön noch wird es allgemein akzeptiert. Darüber hinaus wird der Verschönerungscode (der bereits unglaublich kompliziert ist) für sehr wenig Gewinn stark komplizieren.

Welche Einrückung ist indent=4 gesetztem

var a = 1
    , b = "foo"
    , c = false;

Was eindeutig nicht die erwartete Leistung ist. Und wie würde es mit Tab-Einzügen aussehen?

Wo lebt das Semikolon? Am Ende? Nirgends? (Ich habe beides gesehen und noch mehr)

Dieser Kern ist ebenso veraltet, erleichtert aber das Verständnis der gewünschten Änderung: https://gist.github.com/nemtsov/2864266/revisions

Dies ist ähnlich wie #80, daher dachte ich, dass die Gründe dafür die gleichen sein könnten - einfacheres Unterscheiden und Neuordnen.

Aber in diesem Szenario gibt es im Gegensatz zu #80 eine praktikable Problemumgehung, die diese Anforderungen erfüllt:

var a = 1;
var b = "foo";
var c = false;

Es ist etwas ausführlicher, aber nicht schrecklich.

Wenn jemand #80 implementiert, würde die einfachste Änderung natürlich auch dieses Szenario abdecken.
Wie @evocateur sagte, Pull-Requests willkommen.

@evocateur : Du hast ein Recht auf deine Meinung und das respektiere ich. Persönlich habe ich den Komma-First-Stil immer nicht gemocht, aber im Laufe der Jahre habe ich die Leichtigkeit des Verschiebens, Herausnehmens (Kommentieren, Löschen usw.) und wie @bitwiseman sagt - Differenzieren

@bitwiseman : Auf jeder Meinung nach so aussehen:

var a = 1
  , b = "foo"
  , c = false;

Ich denke, dies stimmt auch damit überein, wie einige SQL-Editoren (wobei Komma zuerst vorherrscht) dies tun.

Und obwohl ich nicht dafür plädiere, schlechte Layouts zu fördern, denke ich, dass es immer einen schmalen Grat zwischen Idiomatik und Dogmatik gibt (denken Sie hier an Crockford). Komma zuerst ist möglicherweise nicht weit verbreitet, da viele Formatierer dies nicht unterstützen, was auch immer der Grund sein mag.

Sie sind mit dem Stand der Dinge in Bezug auf den Code besser vertraut, daher stimme ich Ihrem ROI-Argument vollkommen zu. Trotzdem dachte ich daran, zu fragen, damit wir diese Dinge an die Öffentlichkeit bringen, ein Quorum haben, um Dinge zu diskutieren, und wenn es Nachfrage aus der Community gibt, könnt ihr vielleicht noch einmal darüber nachdenken.

PS Ich habe ein paar Stunden damit verbracht, zu versuchen, ob ich schnell etwas ablösen kann und war nicht sehr erfolgreich. Vielleicht probiere ich es ein anderes Mal.

@mrchief Ich entschuldige mich, dass ich gestern so schroff war, ich machte eine Pause von einer frustrierenden Debugging-Sitzung. Sie machen gute Argumente, und ich möchte klarstellen, dass ich auch Ihre Wahl respektiere. Ich selbst versuche, den Stil eines bestimmten Projekts beizubehalten, wenn ich einen Patch beisteuere (Komma-zuerst, keine Semikolons, andere Verrücktheit), und ich stimme zu, dass Optionen wie diese zumindest dazu beitragen können, ein wenig mehr zu erzwingen Konsistenz in den Projekten, die sie einsetzen.

+1. Ich verwende das Komma-zuerst-Muster wegen seiner Vorteile beim Diffen und Zusammenführen.

Was die Position des Semikolons betrifft: Ich habe es in einen Zeilenumbruch eingefügt, in Übereinstimmung mit dem Schlüsselwort var , wie folgt:

var a
  , b
  , c
;

Ich habe mehrere Projekte gesehen, die das gleiche Muster verwenden.

Außerdem denke ich IMHO, dass es schön wäre, jede Variable in einer separaten Zeile zu halten, auch wenn neben der Deklaration kein Wert angegeben wird. Im obigen Beispiel würde der Verschönerer alles in einer Zeile var a, b, c; gruppieren, was auch den ganzen Zweck der Verwendung des Komma-Faust-Stils unterbricht.

+1 für Komma-zuerst-Unterstützung.

Bei 2-Leerzeichen-Einrückung ist dies die sauberste Art, Variablen anzuordnen:

var foo = true
  , bar = 'hello'
  , something;

Wie wäre es mit 4 Leerzeichen pro Tab? Tatsächliche Registerkarten?

Am Freitag, 8. November 2013 um 9:36 Uhr, Luke Martin [email protected]
schrieb:

+1 für Komma-zuerst-Unterstützung.
Bei 2-Leerzeichen-Einrückung ist dies die aufgeräumteste Art, Variablen anzuordnen
var foo = wahr
, bar = 'hallo'

, etwas;

Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an:
https://github.com/einars/js-beautify/issues/245#issuecomment -28081629

Ich denke, der Kern des Kommas-zuerst-Problems liegt tatsächlich in der Tab-Präferenz.

Ich verwende 2-Leerzeichen-Tabulatoren, und Komma-before ist die einzige Möglichkeit, Variablen anzuordnen, ohne unnötigen Leerraum hinzuzufügen (~ stellen zusätzliche Leerzeichen dar, die hinzugefügt wurden, um die Dinge aneinanderzureihen):

// eww
var foo = true,
  ~~bar = 'hello',
  ~~something;

// yum
var foo = true
  , bar = 'hello'
  , something;

Umgekehrt, wenn Sie Tabulatoren mit 4 Leerzeichen verwenden, sieht Komma-before schlecht aus, und Sie kümmern sich natürlich nicht um die Unterstützung dafür.

// also eww
var foo = true
    , bar = 'hello'
    , something;

Es gibt also Diskussionen über Komma, bevor es einfacher ist, zu kommentieren und zu debuggen und bla bla bla. Aber für mich kommt es nur auf die Ästhetik an. Ich verwende 2-Leerzeichen-Tabulatoren, also muss ich Komma-before verwenden. Derzeit kann ich verschönern nicht verwenden, da ich eine Vorliebe für Tabs mit 2 Leerzeichen habe.

Jetzt weiß ich, dass ich wahrscheinlich in der Minderheit bin, und ich verlange absolut keine Unterstützung für meine kleine Vorliebe. Ich habe gerade meine +1 zur Unterhaltung hinzugefügt. Ich könnte sogar in Erwägung ziehen, selbst Unterstützung hinzuzufügen, wenn ich die Zeit habe.

Danke schön :)

Ich möchte dies für Json-Objekte sehen.

 var a = ({
 a: 1
 ,b: 2
 });

@lukemartin Das ist eine interessante Perspektive! :+1:

Ein weiteres +1 für Comma First Support, für Variablendeklaration sowie Array und Objekte - https://gist.github.com/isaacs/357981

Ich habe an einem Patch gearbeitet, um diese Funktion "on demand" zu unterstützen (der Benutzer kann die Option, zuerst Komma zu verwenden, mit einer von mir erstellten Einstellung aktivieren oder deaktivieren).

Ich habe die folgende Formatierung für die Variablendeklaration erreicht (mit 2 Leerzeichen):

var firstVar = 1
  , secondVar = 2
  , thirdVar = 3
;

Aber ich habe einige Zweifel.

Wie sollten wir Arrays, Objekte und Argumentdeklarationen behandeln? In letzter Zeit verwende ich folgendes Format:

myArray = [
  item1
, item2
, item3
];

myObject = {
  prop1: 1
, prop2: 2
, prop3: 3
}

Was, wie Sie sehen können, nicht genau mit der Formatierung der Variablendeklaration übereinstimmt: Diese letzte enthält eine Einrückungsebene von +1 für die zweite Variable (beachten Sie die beiden Leerzeichen vor dem Komma, die vor dem Komma für "item2" nicht vorhanden sind). noch für den für "prop2"). Var-Deklarationen verwenden diesen zusätzlichen Einzug, um den Anfang jedes Variablennamens in derselben Spalte auszurichten, wie von @lukemartin angegeben.

Die Gründe für die Verwendung der im obigen Code gezeigten Formatierung sind:

1.- Um Linting- Fehler zu

myArray = [
    item1
  , item2
];

Löst "Erwartet ] einen Einzug bei 3 statt bei 1 aus". Wenn wir dem Vorschlag folgen, erhalten wir ein sehr hässliches Ergebnis.

2.- Um den Vorteil beizubehalten, den Anfang jedes Eigenschaftsnamens, Array-Elements usw. auszurichten. Zum Beispiel:

myArray = [
  item1
  , item2
];

Erzeugt auch keinen Linting-Fehler, sieht aber nicht so schön aus wie die obigen Beispiele.

Mit einer klareren Vorstellung davon, wie ich diese Fälle behandeln sollte, könnte ich die Implementierung dieser Funktion abschließen und einen Pull Request ausgeben.

Ist es möglich, all dies zu unterstützen? Alles, was Sie aufgelistet haben, ist technisch "Komma zuerst".

Ich glaube, es könnte möglich sein, aber es wäre notwendig, mehr Einstellungen zu implementieren, die es dem Benutzer ermöglichen, das gewünschte Ergebnis zu erzielen. Zum Beispiel wäre es notwendig, dem Formatierer mitzuteilen, ob Sie 2 Einrückungsebenen für Arrays, Objekte und Argumente verwenden möchten oder nur eine.

Ich denke, es wäre besser, zuerst die Grundfunktionalität zu erreichen und diese dann um weitere Einstellungen zu erweitern. Ich glaube, ich hätte kein Problem damit, diese in einem zweiten Patch zu implementieren.

Wie gesagt, die Grundfunktionalität ist in Ordnung. Es ist ein _Nicht-Ziel_ dieses Projekts, _alle_ Formatierungsoptionen zu unterstützen. :Lächeln:

// 2-space indents
var itemA = 1
  , itemB: 2
  , itemC: 3;

myObj = {
  itemA: 1
  , itemB: 2
}

myArray = [
  item1
  , item2
];

// 4-space indents
var itemA = 1
    , itemB: 2
    , itemC: 3;

myObj = {
    itemA: 1
    , itemB: 2
}

myArray = [
    item1
    , item2
];

Diese sollten Ihren Code einfach und die Formatierung konsistent halten, unabhängig davon, welche Einzüge verwendet werden, und lassen uns dieses Problem schließen und ein neues Problem für "Bezeichner mit Komma zuerst spalten" (oder was auch immer) öffnen, das separat spezifiziert und implementiert werden kann .

Ich freue mich auf Ihren Pull-Request!

@tgirardi Tolle Arbeit. Kann es kaum erwarten, das auszuprobieren.

Alle Rückmeldungen sind willkommen :-) !!!

Meine Idee ist, den Code anzupassen, bis er als die richtige Lösung angesehen wird, und dann mit der folgenden TODO-Liste fortzufahren:

1.- Erstellen Sie Tests für diese neue Funktion
2.- Funktion auf die Python-Version anwenden (Wenn sich jemand freiwillig dafür meldet, umso besser! ... Ich habe nicht viel Erfahrung mit Python).
3.- Besprechen Sie andere mögliche Variationen von Komma-zuerst-Stilen

4-Leerzeichen-Einzug

var x = a
    , y = b
;
obj = {
    attr1: "value1"
    , attr2: "value2"
    , attr3: "value3"
};

Die Variablennamen und Attributnamen müssen nicht aufgereiht werden. Dies hat keinen Einfluss auf die Lesbarkeit. Meiner Meinung nach besteht der Hauptgrund für die Verwendung von Column-First darin, das Kommentieren, Entfernen und Einfügen von Zeilen zu erleichtern. Es passiert nur, wenn Sie 2-Leerzeichen-Einzug verwenden.

Die Semi-Spalte sollte nach der Deklaration mehrerer Variablen in einer eigenen Zeile stehen, um das Anhängen einer neuen Variablen nach 'y' zu erleichtern. In diesem Fall in VIM 'o' + ', z = c' statt '$a,' + 'z = c'

@lewisdiamond Ich stimme Ihrem

Aber es wurde auch festgestellt, dass:

1.- Es ist nicht das Ziel des Projekts, alle Arten von Formatierungen zu unterstützen.
2.- Zu viel Komplexität auf einmal hinzuzufügen ist eine schlechte Idee. Es könnte also besser sein, dieses Feature zuerst so einfach wie möglich zu halten und es zu verbessern, nachdem es einen Release-Status erreicht und einige Zeit getestet wurde

+1 für Komma-First-Support, und ich stimme der Meinung von Lewisdiamond zu, dass es nicht das Endziel sein sollte, sicherzustellen, dass die Tabs richtig ausgerichtet sind, da es pragmatische Gründe für den Komma-First-Stil gibt. Ich würde mich auch über Unterstützung für json freuen. Derzeit habe ich einen Hack im globalen js-beautify-Code, um viele Interpunktions-erste Alternativen zu machen (für ternäre Operatoren ein Muss).

An alle, die dafür +1 gegeben haben: Bitte werfen Sie einen Blick auf die Filiale https://github.com/beautify-web/js-beautify/tree/feature/comma-first .

Sagen Sie mir, ob dies ein ausreichender erster Schritt zu dem ist, was Sie wollen, dass ich es der nächsten Version hinzufügen sollte.

@olsonpm , @lewisdiamond , @lukemartin , @mrchief - https://github.com/beautify-web/js-beautify/tree/feature/comma-first anschauen.

Ich werde heute Abend 30 Minuten damit verbringen und mit Gedanken antworten. Danke fürs Nachfassen.

Bin heute morgen dazu gekommen. Für mich sieht alles gut aus aufgrund deiner Tests. Ich habe einen persönlichen Zweig mit vielen Operator-First-Funktionalitäten - ich habe meine Komma-First-Tests durch Ihren Zweig geführt und alle haben kein Problem bestanden, was großartige Neuigkeiten sind.

Als ich meinen persönlichen Zweig erstellt habe, habe ich beschlossen, dass der Komma-zuerst-Operator passiv ist, was Folgendes bedeutet:

var a,
    b;

würde nicht geändert werden. Sie haben in der Commit-Nachricht klar gesagt, dass dies nicht der Fall ist. Ich denke, es lohnt sich nur, mit anderen zu diskutieren, welches Verhalten sie erwarten würden, wenn sie opt.comma_first verwenden würden.

Eine andere Sache, <Output>.vorherige_zeile und flags.vorheriger_text sind meiner Meinung nach dasselbe, was mich zunächst verwirrend fand, aber in der Art und Weise, wie Sie es verwendet haben, sinnvoll war.

Abgesehen davon besteht der Hauptunterschied zwischen unseren Implementierungen darin, dass Sie sich dafür entschieden haben, die vorherige Zeile zu ändern. Ich habe versucht, nicht "zurückzugehen und Dinge zu bearbeiten", weil ich dachte, es wäre verwirrender, es zu entwickeln. Jetzt ist Ihr Weg prägnanter als meiner - er ist leicht zu lesen und Sie haben alles kommentiert. Der vorhandene Code bearbeitet auch frühere Token, sodass Ihr Code perfekt in Einklang steht. Ehrlich gesagt, erwähne ich ihn nur, weil ich Ihre Meinung dazu wissen möchte. Kurz gesagt, ich bin der Meinung, dass dieses Programm viel einfacher zu debuggen wäre, wenn Token nur für den Leerraum vor ihnen basierend auf den nächsten Token verantwortlich wären.

Danke, dass du das ansprichst!

Bearbeiten: Mein Fehler - <Ausgabe>.vorherige_zeile und flags.vorheriger_text sind völlig unterschiedlich.

Forward-only ist vorzuziehen. Ich habe mir den Haarball angesehen, wie und wo wir entscheiden, was mit / über Kommas zu tun ist. Es gibt bereits Stellen, an denen wir die Ausgabe zurückschneiden, um sie an die richtige Stelle zu bringen. Ich beschloss, etwas vereinfachtes zu tun, einige Tests durchzuführen, die das vereinfachte Verhalten überprüfen und dann später über die Optimierung und Umgestaltung nachsehen.

Das von Ihnen genannte Beispiel:

var a,
    b;

Wäre ein Beispiel für Tuning, das später besprochen werden könnte.

Hört sich gut an. Ich schätze das Feedback.

Und vielen Dank fürs Durchsehen. Wenn Sie Tests hinzufügen möchten, wäre dies eine große Hilfe.