PHP Richtlinien

[T!P-TOP]

PHP Programmierung Richtlinien | Buxaprojects Auf diesen Artikel bin ich gerade zufällig gestoßen. Beschrieben wird da die optimale Schreibweise von PHP Datein und deren Inhalt - das kann man wohl jedem Einsteiger ans Herz legen. Ein paar Dinge kann ich aber nicht ganz nachvollziehen.

Klassennamen dürfen nur alphanumerische Zeichen enthalten. Zahlen sind erlaubt, jedoch zu vermeiden. Underscores sind nur an der Stelle des Pfadseperators erlaubt. Zum Beispiel der Datei mit dem Pfad "Buxa/Db/Table.php" muss die Klasse "Buxa_Db_Table" enthalten.

Sollte man diesen Stil heutzutage noch beibehalten, wo es doch namespaces gibt? Wenn ja, wieso?

Bei Dateien, die nur PHP-Code enthalten, ist der Abschlusstag ("?>") wegzulassen. Von PHP wird dieser nicht benötigt und verhindert so unerwünschte Leerzeichen beim finalen Output.

Durch ?> enstehen Leerzeichen am Ende einer php Datei? Oder wie ist das zu verstehen?

Klassenvariablen müssen die folgenden Namenskonventionen einhalten. Alle, in einer Klasse verwendeten, Klassenvariablen müssen innerhalb der Klasse zuoberst aufgelistet werden. Erst darunter folgen die Klassenmethoden. Das "var" Konstrukt ist nicht erlaubt. Klassenvariablen sind immer nach Sichtbarkeit zuzuordnen. Das heisst mit den "private", "protected" oder "public" Konstrukten. Klassenvariablen dürfen als public definiert werden, ist jedoch zu vermeiden. Verwenden Sie die Zugriffsmethoden mit "set" und "get" als Präfix.

Was das bringen soll, habe ich eigentlich noch nie so ganz verstanden. Ob ich nun auf die mit public definierte Eigenschaft direkt zugreife oder ob ich es umständlicher mit einer set oder get Methode mache, spielt doch keine Rolle - oder etwa doch?

Variablennamen dürfen nur aus alphanumerischen Zeichen bestehen. Underscores sind nicht erlaubt. Zahlen sind erlaubt, jedoch zu vermeiden. Klassenvariablen, welche mit "private" oder "protected" deklariert sind, müssen mit einem einfachen Underscore beginnen. Dies ist der einzige Fall, in dem ein Underscore im Variablenname vorkommen darf.

Private Klassenelemente mit nem underscore zu kennzeichnen ist nichts neues, aber auch die, die als protected definiert sind? Ergibt für mich keinen Sinn. Löst Ihr das gleich, wie im Zitierten text beschrieben? Grüße

 

[NetAktiv]

Ich will mal nur zum Set/Get antworten. Prinzipiell ist es egal, wenn die Werte egal sind. Aber man verwendet die Get/Set Methoden, um eventuell notwendige Validierungen durchzuführen, beispielsweise ob ein Zahl auch in einem bestimmten Bereich ist oder eine Email-Adresse auch güliges Format hat oder .... Außerdem können im Objekt von einer Property noch andere abhängen, so kann man in der Set Methode dafür sorgen, dass das Objekt in sich konsistent ist.

 

[crash]

Sollte man diesen Stil heutzutage noch beibehalten, wo es doch namespaces gibt? Wenn ja, wieso?

Gerade bei Namespaces. Diese Richtlinie ist unvermeidbar, wenn ein Autoloader solche Klassen finden soll.

Durch ?> enstehen Leerzeichen am Ende einer php Datei? Oder wie ist das zu verstehen?

Hier geht es darum zu vermeiden, dass Leerzeichen/Umbrüche vom Ende der Datei in den Output gelangen.

Was das bringen soll, habe ich eigentlich noch nie so ganz verstanden. Ob ich nun auf die mit public definierte Eigenschaft direkt zugreife oder ob ich es umständlicher mit einer set oder get Methode mache, spielt doch keine Rolle - oder etwa doch?

Zur genannten Vailidierung, ermöglicht das ganze noch einfach solche Getter/Setter-Methoden durchzuschleifen (ArrayAccess, Iteratoren) und bestimmte Operationen auf den Wert auszuführen (sei es nur casten).

Private Klassenelemente mit nem underscore zu kennzeichnen ist nichts neues, aber auch die, die als protected definiert sind? Ergibt für mich keinen Sinn. Löst Ihr das gleich, wie im Zitierten text beschrieben?

Ich kennzeichne Variablen genauso und so machen es auch die allermeisten. Dass Methoden/Variablen mit „protected“ mit einem Underscore zu kennzeichnen sind ist meiner Meinung nach aber Blödsinn, da solche Eigenschafen/Methoden auch eine Art Interface für die erweiternden Klassen sind. Darum geht es eigentlich, diese Schnittstellen zu trennen (über Ihre Sichtbarkeit hinaus).

 

[mermshaus]

Klassennamen dürfen nur alphanumerische Zeichen enthalten. Zahlen sind erlaubt, jedoch zu vermeiden. Underscores sind nur an der Stelle des Pfadseperators erlaubt. Zum Beispiel der Datei mit dem Pfad "Buxa/Db/Table.php" muss die Klasse "Buxa_Db_Table" enthalten.

Separator. ;)

Bei der Verwendung von Namespaces würde die Klasse grob äquivalent Table heißen und sich in einem Namespace Buxa\DB befinden. Anders gesagt: Wenn Namespaces verwendet werden, sind Unterstriche im Klassennamen unnötig. Ansonsten sind sie allerdings der Standard für Autoloading-Zwecke.

Durch ?> enstehen Leerzeichen am Ende einer php Datei? Oder wie ist das zu verstehen?

Ja, die führen dann gerne zu „Headers already sent“-Fehlermeldungen im Umgang mit Sessions, da sie Output sind.

Mit Whitespace an der Stelle hatte ich persönlich glaube ich noch nie Probleme, aber es ist definitiv guter Stil, in Dateien, die keine Templates sind, auf den abschließenden Closing-Tag zu verzichten. Das ist Standard und bei Nichtbeachtung häufig ein Indikator für schlechten Code.

Es ist darüber hinaus nicht verkehrt, zum Beispiel Klassen-Dateien mit einer Leerzeile (\n) zu beenden, da das zu einer „saubereren“ Ausgabe auf der Kommandozeile führt. (Ansonsten ist etwa der nächste Eingabe-Prompt in derselben Zeile wie die letzte Zeile der Datei.) Diverse Versionskontrollsysteme geben bei fehlender Leerzeile in bestimmten Kontexten sogar eine Meldung aus.

- github - Git: no newline at end of file - Stack Overflow

Man kann es aber auch übertreiben.

Klassenvariablen dürfen als public definiert werden, ist jedoch zu vermeiden. Verwenden Sie die Zugriffsmethoden mit "set" und "get" als Präfix.

Dazu wurde im Grunde alles gesagt, aber noch ein wenig als Hintergrund: Auf php.de wurde neulich ein Google-Guide zur Geschwindigkeitsoptimierung verlinkt, der empfiehlt, auf Getter und Setter zu verzichten.

Das ist ein diskutables Thema, zu dem es diverse Meinungen gibt, die alle nicht unbedingt falsch sind.

Ich bin ein Verfechter von expliziten Gettern und Settern, da sie – wie beschrieben – Validierung ermöglichen, was relativ häufig notwendig ist. Würden dann Instanzvariablen, die keine Validierung benötigen, „öffentlich“ ohne Getter/Setter implementiert, ergäbe sich ein inkonsistentes API, das teilweise Methodenaufrufe zum Setzen von Instanzvariablen benötigt und teilweise nicht. Das ist meiner Meinung nach unnötig verwirrend und deshalb unschön.

Es gibt allerdings mitunter Objekte (meist als Ersatz für assoziative Arrays), die so wenig (besser gesagt: gar keine) Logik enthalten, dass Getter/Setter „aus praktischer Faulheit“ ausgelassen werden – also keine Regel ohne Ausnahme.

In PHP erschweren außerdem magische Methoden zum Setzen/Auslesen von Instanzvariablen solche Diskussionen zusätzlich.

Private Klassenelemente mit nem underscore zu kennzeichnen ist nichts neues, aber auch die, die als protected definiert sind? Ergibt für mich keinen Sinn. Löst Ihr das gleich, wie im Zitierten text beschrieben?

Das ist meiner Meinung nach eine Glaubensfrage (ein wenig wie ungarische Notation). Die inhaltliche Begründung für Unterstriche ist auch historisch motiviert. Früher gab es zur Definition der Sichtbarkeit nur var, was dem heutigen public entspricht. Um herauszustellen, dass dennoch nicht alle Instanzvariablen öffentlich sein sollen, musste deshalb auf die Kennzeichnung mit Unterstrichen ausgewichen werden.

Je „genauer“ eine Sprache und je leistungsfähiger die IDEs, desto weniger besteht Notwendigkeit für solche Kennzeichnungen. Wenn eine IDE private Instanzvariablen in hellgrün und kursiv darstellt, braucht es keinen Unterstrich mehr, um die Sichtbarkeit zu erkennen. Andererseits kann das natürlich nicht jeder Editor.

Ich halte beide Sichtweisen für vertretbar, bin jedoch – ohne das großartig begründen zu können – dazu übergegangen, kein Unterstrich-Präfix mehr zu setzen. (Es mag damit zusammenhängen, dass ich praktisch ausschließlich protected verwende. :))