Warum ist Wordpress-Code so "space-happy"?

Der WP-Kern, viele WP-Plugins und die WP-Codierungsstandards selbst verwenden eine sehr "großzügige Anwendung" des SpaceZeichens (nicht zum Einrücken, sondern "innerhalb" von Parens und Klammern). Dies scheint einzigartig für Wordpress zu sein - dieser Stil / diese Philosophie scheint in anderen ähnlichen Projekten, PHP oder auf andere Weise, nicht vorhanden zu sein.

Weitere Informationen zu diesem Ansatz finden Sie unter: https://make.wordpress.org/core/handbook/coding-standards/php/#space-usage

Beispiel: foreach ( (array) $foo as $bar ) { ...

Ich beziehe mich auf den Bereich nach foreach, nach dem ersten (und vor dem letzten )(und auf andere ähnliche Bereiche, die unter "Space Usage" unter dem obigen Link aufgeführt sind).

Dieser Stil erscheint mir unnötig - er erfordert mehr Eingaben und erschwert das Parsing von Code visuell (/ opinion).

Mein Wunsch ist es nicht zu diskutieren, ob dieser Stil eine gute Idee ist oder nicht. Ich möchte vielmehr nur die Motive verstehen, warum dies der empfohlene Stil ist. Sogar Kommentatoren der WP-Kodierungsstandards sind neugierig:

Bildbeschreibung hier eingeben

Die Antworten auf die Frage von MK Safi lauten im Wesentlichen:

Zur besseren Lesbarkeit
Status quo (auch bekannt als "So ist es eben")

Meine Begründung für die Frage ist, dass ich persönlich nicht viel Wert darin sehe, die WP-Codierungsstandards (in Bezug auf "Space Usage") in unseren internen Projekten zu übernehmen. Ich bin jedoch gespannt, ob mir etwas fehlt.

Gibt es Gründe, die über die beiden oben aufgeführten Gründe hinausgehen und angeblich gültig sind oder nicht, um dem "Space Usage" -Stil von Wordpress zu folgen?

coding-standards

— rinogo
quelle

Sie können in Ihren internen Projekten tun, was Sie möchten, solange Sie konsistent sind. Als Randnotiz verwenden wir Tabulatoren anstelle von Leerzeichen, sodass wir wahrscheinlich weniger Eingaben benötigen. Dies ist jedoch in keiner Weise von Bedeutung, wenn Sie eine moderne IDE haben, die die gesamte Formatierung für Sie übernimmt und Sie in verschiedene Stile formatieren können (z. B. Sublime) mit Paketen, PHPStorm usw.)

— Tom J Nowell

Danke für deinen Kommentar, @TomJNowell! Ich glaube, ich habe mich in meiner "Frage" falsch verständigt - ich frage weniger nach Tabulatoren / Leerzeichen für Einrückungen als vielmehr nach den Regeln, die unter "Space Usage" unter make.wordpress.org/core/handbook/coding-standards/php aufgeführt sind /… . Entschuldigung, ich war nicht klarer!

— Rinogo

Es ist einfacher zu lesen, wenn Sie keine Syntaxhervorhebung haben. Zumindest deshalb verwende ich diesen Stil in internen Projekten. Ich muss PHP oft in einer einfachen Konsole mit vi in einer minimalen Konfiguration bearbeiten.

— Fuxia

FWIW, MediaWiki hat eine sehr ähnliche Stilkonvention und ist eigentlich ziemlich streng bei der Durchsetzung (zumindest im Kern). Sie haben sogar ein Skript zum automatischen Hinzufügen fehlender Leerzeichen. Ich kann nur sagen, dass man sich nach einer Weile daran gewöhnt.

— Ilmari Karonen

@Rinogo Ich weiß, Kommentare sind manchmal nur Kommentare, keine Antworten :)

— Tom J Nowell

Antworten:

Resonanz

In Bezug auf "Leerzeichen" (egal ob Tabulatoren oder Leerzeichen): Es ist einfach eine persönliche Vorliebe, die am Projekt festhielt.

Die WP-Kodierungsstandards imo sind ein Chaos und können ignoriert werden - solange Sie nicht zum Kern beitragen, was ist

eine andere Geschichte und
Styleguide wird dort ebenfalls ignoriert.

"[...] es wird nicht rückwirkend in großen Mengen auf älteren Code angewendet, da dies die Verwendung von svn / git - Verlauf sehr schwierig macht. Die offizielle Richtlinie lautet, dass neuer Code der Stilrichtlinie folgen sollte, aber wenn Sie angrenzenden Code korrekt formatieren dann sei es so, aber Patches, die nur Code formatieren, oder Commits, die nur Code formatieren, sind verboten. "

^{- @ TomJNowell in den Kommentaren}

Alternativen

Sie sollten sich besser an die PSR- Standards (nämlich: 2) oder an Dinge wie die Symfony-Standards (oder nur an Ihre eigenen) halten.

Leistungssteigerung & Tools

Es gibt keinen Gewinn für Sie, wenn Sie einen Kodierungsstandard haben (abgesehen davon, dass Sie einen teilen müssen und die Minderheit, die ihn hasst, während der Rest ihn diktiert) oder wenn Sie mehr oder weniger Tabulatoren oder Leerzeichen haben. Falls Sie sich Sorgen über unnötigen Speicherplatz oder möglicherweise langsamere Programme machen, können Sie Ihren Code beim Festschreiben trotzdem komprimieren (siehe das GitPHPHooks-Projekt ). Der Nutzen, den Sie daraus ziehen, liegt bei maximal 5% des ursprünglichen Dateibereichs. Dies entspricht in etwa dem, was Sie durch die Komprimierung / Minimierung der HTML-Syntax erhalten. Dafür gibt es die Minify-Tools von Node.js, die über npm verfügbar sind.

Was ich persönlich wirklich hilfreich fand, ist der PHP Linter und der _PHP Mess Detector. Ich habe beide in die GitPHPHooks-Bibliothek aufgenommen, damit ich nicht daran denken oder daran denken muss, sie auszuführen .

— Kaiser
quelle

Der Styleguide wird für Core nicht ignoriert, aber nicht rückwirkend in großen Mengen auf älteren Code angewendet, da er die Verwendung von svn / git history sehr schwierig macht. Die offizielle Richtlinie lautet, dass neuer Code dem Styleguide folgen sollte. Wenn Sie jedoch angrenzenden Code korrekt formatieren, sollten Sie dies auch tun, aber Patches, die nur Code formatieren, oder Commits, die nur Code formatieren, sind verboten

— Tom J Nowell

@TomJNowell Und macht daher den Styleguide unbrauchbar :) Wie auch immer, reichen Sie eine Bearbeitung ein und fügen Sie diese der Antwort hinzu. Es ist bemerkenswert, Info.

— Kaiser

Ich glaube, ich war in meiner Frage nicht ganz klar - ich beziehe mich weniger auf Tabs vs. Spaces als vielmehr auf "Space Usage" unter make.wordpress.org/core/handbook/coding-standards/php/… . Ich werde die Frage bearbeiten, um sie klarer zu gestalten.

— Rinogo

@rinogo Ich habe dich gleich richtig verstanden, daher der erste Absatz. Übrigens halte ich das auch für lesbarer.

— Kaiser

Leerzeichen nach Punkten sind normal, z. B. $baz . '-5'wird dieser Stil in vielen Codierungsstandards für Operatoren ( y + z) verwendet.

Dies geschieht, um die Lesbarkeit zu verbessern. Zum Beispiel ist eine davon besser lesbar als die andere.

$cow.$dog.$cat.$table.$chocolate.$puddle.$iterator.$stuctureone.$stucturetwo

$cow . $dog . $cat . $table . $chocolate . $puddle . $iterator . $stuctureone . $stucturetwo

Dies wird noch deutlicher, wenn es von anderem "Code" umgeben ist.

Wie für Leerzeichen um Klammern ( 1, 2, 3 )Ich habe keine Ahnung, was betrifft. Ich denke, das Argument ist auch für die Lesbarkeit.

Es kann verwirrend sein, da die WordPress- Standards selbst Beispiele mit Klammern in Kommentaren enthalten, die keine Leerzeichen enthalten, und die Codebasis selbst verwirrend ist, wenn einige Teile Leerzeichen enthalten und andere nicht (siehe Abbildung unten), selbst innerhalb derselben Funktion.

Die meisten PHP-Standards machen genau das Gegenteil. Klammern sollten ihren Inhalt umarmen. Tatsächlich schreiben die meisten Codierungsstandards für andere Sprachen so:(1, 2, 3) Es ist also ein bisschen rätselhaft, warum WP es so macht.

Hier ist ein Vergleichsbeispiel einer WordPress-Funktion.

Bildbeschreibung hier eingeben

Größere Version zum Vergleichen: http://i.imgur.com/nTEbV7v.jpg

Ich bevorzuge die auf der rechten Seite, vor allem, wenn ich mir den gesamten Codebildschirm ansehe, aber es ist eine persönliche Präferenz.

— Wyck
quelle

Danke für deine Antwort! Der .Abstand macht für mich Sinn, da .es sich eigentlich nur um einen binären Operator handelt, genau wie +oder -. Deine Gedanken über Klammern, die ihren Inhalt "umarmen", sind genau der Grund, warum ich diese Frage gestellt habe. Dieses Verhalten ist genau der Grund, warum ich diese Frage gestellt habe , zusammen mit den noch seltsameren Regeln wie denen für eckige Klammern (WP sagt zu verwenden $foo['bar']und $foo[ $bar ]). :)

— rinogo