IMC hat geschrieben: 26.07.2023 00:34
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.
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.
