HowTo: EditorConfig - Editor-übergreifende Formatvorgaben

[IMC]

Ich kenne im Moment keine Situation bei der Leerzeichen oder Tabulatoren am Zeilenende einen Vorteil haben könnten.

Ich glaube mich zu erinner, dass ich in meinen Anfängen bestimmte Effekte mit Leerzeichen erreichen wollte, die dann aber nicht eintraten.

Ich habe deine Änderung schon übernommen.

[LukeWCS]

Mike-on-Tour, Dr.Death, IMC, schon mal danke für euren Input bisher.

Das bestätigt schon mal meine Überlegungen. Denn der Browser arbeitet ja ohnehin nicht direkt mit dem HTML das wir ihm liefern, der zerlegt das sowieso in seine Einzelteile und erstellt daraus das DOM Objekt. Und da sind Whitespaces nach Tags ohnehin bedeutungslos, also z.B. Leerzeichen, Tabs und Linefeeds. Mehrere Whitespaces - inklusive Linefeeds - zwischen 2 Tag Container, werden vom Browser als 1 Leerzeichen gehandhabt.

Nach meiner Überlegung wären "eigentlich" nur Text-Abschnitte relevant, die eine fixe Textbreite haben mit harten Zeilenumbrüchen. Da sind aber auch fehlende Whitespaces am Ende der Zeilen kein Problem.

Mir gings einfach nur darum, ob es noch irgendwelche anderen Situationen geben könnte, wo Whitespaces am Zeilenende relevant sein könnten. Sprich, Dinge die ich eben nicht auf dem Radar habe. Weil, einen quasi etablierten Standard ändern, muss man sich schon gut überlegen, weil das gleich viele betreffen würde, die diesen Standard nutzen.

[Kirk]

Das mit den whitespace sehe ich genauso wie meine Kollegen.

[LukeWCS]

Version 1.1 des Standards jetzt in der Knowledge Base.

Änderungen im KB Eintrag:

• Eine Übersicht hinzugefügt.
• Texte überarbeitet.
• Punkte neu nummeriert.
• Die Version 1.0 des Standards in einen Spoiler "archiviert", damit Änderungen am Standard nachvollziehbar bleiben.

[IMC]

Mir war aufgefallen das in der composer.json bei den Einrückungen mal Tabs, mal Leerzeichen verwendet werden. Irritiert hat mich das dies auch bei offiziellen Extensions unterschiedlich gehandhabt wird. Deshalb habe ich ein bisschen recherchiert.

Nach dem Überfliegen von einigen Seiten im Netz habe ich festgestellt das es eigentlich egal ist. Man aber aus kompatibilitäts Gründen zu PHP, 4 Leerzeichen nutzen sollte. Der entscheide Beitrag für meine Entscheidung eine Änderung für die .editorconfig vorzuschlagen war dieser.
https://wiki.php.net/rfc/json_encode_indentation

Mein Vorschlag:

Code: Alles auswählen

[*.{json,yml}]
indent_style = space

[Dr.Death]

Ja, macht Sinn, dafür.

[Mike-on-Tour]

Ist bei mir schon so.

[LukeWCS]

Mir war aufgefallen das in der composer.json bei den Einrückungen mal Tabs, mal Leerzeichen verwendet werden. Irritiert hat mich das dies auch bei offiziellen Extensions unterschiedlich gehandhabt wird.

Da kann ich die Erklärung liefern, da ich vor paar Jahren bei einer Ext (LFWWH) auch über diesen Punkt gestolpert bin. Des Rätsels Lösung ist Titania (das CDB System). Beim hochladen in die CDB wird die composer.json bei Bedarf automatisch neu erstellt, zum Beispiel um die Versionsprüfung hinzuzufügen. Und bei diesem Schritt werden zwangsläufig Einrückungen per Tabs durch Einrückungen per Spaces ersetzt. Wenn du also Exts findest, bei denen noch Tabs vorhanden sind, dann wurde bei denen die composer.json durch Titania nicht neu erstellt.

Genau diesen Punkt hatte ich damals im Zuge der Validierung auch kritisiert, weil wir als Ext Coder überall dazu angehalten werden Tabs bei Einrückungen zu verwenden, mit Ausnahme natürlich bei YAML. Es wäre also nur konsequent, wenn auch bei composer.json durchgängig Tabs verwendet werden. Leider kommt uns da die Technik in die Quere:

Nach dem Überfliegen von einigen Seiten im Netz habe ich festgestellt das es eigentlich egal ist. Man aber aus kompatibilitäts Gründen zu PHP, 4 Leerzeichen nutzen sollte.

Rein technisch gesehen ist es für PHP irrelevant, ob mit Spaces oder Tabs eingerückt wurde. Der JSON Parser ignoriert sowieso jegliche "unnötigen" Whitespaces und dazu gehören die optischen Einrückungen, denn das ist ein künstliches Konstrukt für Menschen, damit diese eine solche Datenstruktur leichter lesen können. Für die Maschine, in dem Fall Software und in diesem spezifischen Fall PHP, ist das aber komplett bedeutungslos.

Im Standard von JSON sind Spaces für Einrückungen meines Wissens auch nicht vorgeschrieben. Nur PHP nutzt halt Spaces bei der Erzeugung einer JSON Struktur und lässt dem Coder leider nicht die Wahl. Das ist der springende Punkt.

Der entscheide Beitrag für meine Entscheidung eine Änderung für die .editorconfig vorzuschlagen war dieser.
https://wiki.php.net/rfc/json_encode_indentation

Ja, wobei es in der Umfrage primär darum ging, einen vierten Parameter für json_encode hinzuzufügen, mit dem Coder die Einrückungsbreite festlegen können. Nur am Rande: Wenn ich mich so bei den Coder Kollegen umschaue, Hobby wie Beruflich, dann liegen die Standpunkte bezüglich Einrückungen (Tabs oder Spaces) sowie Einrückungsbreite auch sehr weit auseinander. Ein grosser Teil favorisiert inzwischen eine Breite von 4 Spaces, für andere ist selbst das schon "Verschwendung" und sie nutzen nur 2 Spaces, das sind aber nur wenige. Dann gibts auch noch Hardliner die die Meinung vertreten, das ein Tab eine gottgegebene Breite von 8 Spaces hat und alles andere Ketzerei ist. Das sind aber auch nur wenige und die werden auch immer weniger. ^^

Persönliche Meinung: Spaces sind unflexibel, weil man dann nicht selber festlegen kann, wie breit eine Einrückungsebene aussehen soll. Eine Datenstruktur mit Spaces statt Tabs bläht die Datei ausserdem nur unnötig auf. Mit Tabs wird eine Datei kompakter. Aber okay, das ist jetzt nicht so das entscheidende Kriterium, denn da wo wir wir mit JSON zu tun haben, sind das ja alles nur "winzige" Dateien. Bei phpBB Ext Check nutze ich übrigens auch JSON zur Datenspeicherung; für Statistik und Cache.

Mir wären Tabs generell lieber, da flexibler und kompakter. Wenn man allerdings die Tatsache heranzieht, dass spätestens beim Hochladen einer Ext die composer.json sowieso fallweise von Titania mit Spaces neu erstellt wird, könnten wir auch gleich den Standard auf Spaces ändern.

[Crizzo]

https://area51.phpbb.com/docs/dev/3.3.x ... #json-yaml

[IMC]

... dann liegen die Standpunkte bezüglich Einrückungen (Tabs oder Spaces) sowie Einrückungsbreite auch sehr weit auseinander. Ein grosser Teil favorisiert inzwischen eine Breite von 4 Spaces, für andere ist selbst das schon "Verschwendung" und sie nutzen nur 2 Spaces, das sind aber nur wenige. Dann gibts auch noch Hardliner die die Meinung vertreten, das ein Tab eine gottgegebene Breite von 8 Spaces hat und alles andere Ketzerei ist. Das sind aber auch nur wenige und die werden auch immer weniger. ^^

Wegen diese unterschiedlichen Befindlichkeiten ist der 4te Parameter in json_encode() auch eingeführt worden. Vorher waren 4 Spaces mit dem setzen des pretty flags fix gesetzt.

Mir wären Tabs generell lieber, da flexibler und kompakter.

Ich finde Tabs auch flexibler da jeder durch seine Einstellungen im Editor seine bevorzugte Einrücktiefe konfigurieren kann ohne Änderungen im Code vorzunehmen.

Wenn man allerdings die Tatsache heranzieht, dass spätestens beim Hochladen einer Ext die composer.json sowieso fallweise von Titania mit Spaces neu erstellt wird, könnten wir auch gleich den Standard auf Spaces ändern.

Meine Motivation für die Anpassung der .editorconfig war letztendlich dass mit dem 4ten Parameter die Möglichkeit besteht die Anzahl der Leerzeichen vorzugeben, jedoch kein Tab ausgewählt werden kann. Deshalb sehe ich die Leerzeichen als den PHP Standart für JSON-Dateien.

Jetzt sehe ich gerade das Crizzo die Stelle bei com gefunden hat die ich suchte.