PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : Stilfragen zum Programmieren in PHP


RattuS
2011-02-26, 19:15:05
Hallo,

ich fummele jetzt schon gut 3 Jahre lang in PHP rum, finde aber einfach keine zufriedenstellenden Methoden rund um den Programmierstil bei PHP. Vielleicht liegt es auch einfach nur an der Sprache selbst. Folgende Fragen:

Übersichtlichkeit bei PHP in HTML:
Inline-PHP ist bequem und übersichtlich, aber leider nicht überall einsetzbar. Sobald ich mehrere Variablen verarbeite, eine Bedingung prüfe oder eine Schleife erzeuge, benötige ich mehrere Zeilen PHP, womit das HTML wieder zerschnitten wird. Ich arbeite mitlerweile nur noch im PHP-Tag und printe einfach alle Zeilen HTML. Das hat den Vorteil, dass ich besser zwischen eigentlichem PHP und HTML-Tags unterscheiden kann. So oder so ist das Indent dann aber wieder häßlich, da ich im PHP selbst bedingtes Ident habe, während das HTML-Ident ja nach wie vor Bezug auf deren Parent-Tags hat. Wie lösen die Profis das?

Variableninitialisierung:
Aus einer strengen Programmierumgebung kommend, schmeckt mir dieses fehlertolerante System eigentlich gar nicht. Auf der anderen Seite lässt es sich gleichzeitig für eine schnellere Verarbeitung ausnutzen. Ein gutes Beispiel sind die ganzen Eingabe-Elemente, dessen Werte ich einfach direkt auf GET/POST/SQL (bei vorangehender Maskierung) setzen kann. Selbst wenn die Werte, die verknüpft werden sollen, gar nicht existieren, ist das dank der leeren Rückgabe durch PHP unproblematisch. Oft kann ich mir isset() oder count() direkt sparen, weil sich die Rückgabe bei leeren Werte äquivalent verhält. Trotzdem ist das natürlich irgendwo ein schmutziger Stil. Ist das so gewollt oder bricht mir das irgendwann das Genick?

Objektorientierung:
Es mag vielleicht daran liegen, dass ich überwiegend nur mit überschaubaren Konzepten arbeite oder die Daten nur aus GET/POST und SQL hole, aber so wirklich notwendig erscheint mir Objektorientierung bei PHP nicht, vor allem, weil die Sprache ansich ja schon überwiegend nur mit klassenlosen Funktionen kommt. Ist es empfehlenswert trotz geringer Komplexität eine Klassenhierarchie zu nutzen?

Includes/Requires:
Mir ist aufgefallen, dass man leicht seiner eigenen Bequemlichkeit verfällt, wenn es um das Importieren geht. Gerade bei zeitkritischer Verarbeitung ist es nicht gerade sinnvoll, seine Lieblingsbibliothek einzubinden, die 30 Funktionen beinhaltet, man daraus aber nur genau eine Funktion braucht. Das wiederum bedeutet, dass man viele kleine Bibliotheken daraus machen sollten, was dann aber wieder den Nachteil hat, dass man einen halben Bildschirm voll Imports hat. Letzterer Fall ist im Endeffekt trotzdem schneller oder?

Settings und Lokalisierung:
Um konstante Variablen und lokalisierte Strings zu implementieren, importiere ich (via require_once) diese Definitionen auf jeder Seite, die sie nutzen. Ist das so in Ordnung oder gibt es eine bessere Variante damit umzugehen?


Das sind die Fragen soweit, die mir spontan eingefallen sind. More to come...

Marscel
2011-02-26, 20:27:32
Übersichtlichkeit bei PHP in HTML: ... Wie lösen die Profis das?

Templates. Bei PHP kannst du dir Smarty oder so mal angucken, oder was eigenes bauen, ist nicht so kompliziert.

Variableninitialisierung: ... Ist das so gewollt oder bricht mir das irgendwann das Genick?

Wenn du einen strengen Typenvergleich brauchst, musst du "===" nutzen. Ansonsten ist PHP in dieser Hinsicht tw. sehr übel.

Objektorientierung: ... Ist es empfehlenswert trotz geringer Komplexität eine Klassenhierarchie zu nutzen?

Wenn man nun nicht großartig Abstraktion und Erweiterbarkeit plant, nein (zumindest nach mir nicht).

Includes/Requires: ... Letzterer Fall ist im Endeffekt trotzdem schneller oder?

Ich würde mal behaupten, dass das zu vernachlässigen ist. In einer production-Umgebung sollte man sich sinnvollerweise eine Cache-Extension zulegen, sowie eAccelerator, dann ist die Frage eigentlich auch überflüssig. Und selbst wenn nicht, wenn wir nun nicht von Megabytes reden, dann dürfte eine Datei immer noch schneller sein. Muss aber gestehen, dass ich das Verhältnis von Festplattenseekzeit zu PHP-Interpreterzeit nicht kenne.

Settings und Lokalisierung: ... Ist das so in Ordnung oder gibt es eine bessere Variante damit umzugehen?

Was du halt brauchst, für ne Handvoll Texte sicher Ok. Ansonsten kannst du dir auch Gettext für PHP angucken.

DanMan
2011-02-26, 22:43:55
Übersichtlichkeit bei PHP in HTML:
Interessiert es dich wirklich wie das HTML eingerückt bzw. umbrochen wird? Ich analysiere das am Ende immer über Firebug und Co., und dann kann mir das völlig egal sein. Hauptsache dein PHP ist übersichtlich.

Variableninitialisierung:
Es ist Fluch und Segen zugleich. Einerseits erspart dir die implizite Typisierung (http://de.wikipedia.org/wiki/Typisierung_(Informatik)) Schreibarbeit, andererseits kann es zu unerwarteten Ergebnissen kommen, wenn man an einer Stelle nicht bedacht hat, welchen Wert ein bestimmter Ausdruck am Ende haben kann. NULL ist eben nicht immer das Gleiche wie FALSE. Darum besser Werte streng vergleichen, wenn möglich - wie Marscel schon schrieb.

Objektorientierung:
Macht Sinn je umfangreicher deine Anwendung und je mehr Leute am gleichen Projekt arbeiten. PHP erlaubt es einem aber auch den Quelltext Stück für Stück umzubauen, falls man den Umfang falsch eingeschätzt hat.

Settings und Lokalisierung:
So lange du require_once() benutzt passt das schon.

Generell kannst du dein error_reporting auch auf E_NOTICE stellen, dann werden dir auch Vorschläge für saubereren Stil gemeldet. :)

creave
2011-02-26, 23:05:54
Die schwache Typisierung seitens PHP finde ich auch nicht so prickelnd, aber ist natürlich eine persönliche Präferenz. Jedoch finde ich auch heute noch neue Sachen die ich zuvor nicht wusste, z.B. dass in "tieferen" Scopes deklarierte Variablen auch später außerhalb nutzbar sind, es gibt eigentlich nur noch lokale Variablen bezüglich Funktionen bzw. Methoden.

RattuS
2011-02-26, 23:07:02
Übersichtlichkeit bei PHP in HTML:
Interessiert es dich wirklich wie das HTML eingerückt bzw. umbrochen wird?
Wie das in der Ausgabe am Ende aussieht, ist mir egal, nur lege ich auf formatiertes HTML während der Entwicklung wert, weil ich oft neue Einträge einschiebe oder CSS-Klassen ändere.

Das mit den Templates werde ich auf jeden Fall bei meinem nächsten Projekt einsetzen. Der Umbau bei meinem jetzigen Projekt wäre etwas mühselig und außerdem benötige ich dort jede µs, die ich kriegen kann. ^^

Danke für die Antworten, ihr beide. Hat mir schon mal sehr geholfen. :)

DanMan
2011-02-27, 00:26:07
Keine Ursache.

Stichwort Templates: http://articles.sitepoint.com/article/beyond-template-engine

Mehr brauchts in 99% der Fälle nicht. Smarty und dergleichen find ich überdimensioniert. PHP ist letztlich selbst eine Templatesprache - noch eine samt Parser draufsetzen macht keinen Sinn.

AlecWhite
2011-02-27, 05:03:15
Übersichtlichkeit bei PHP in HTML:


Persönlich verwende ich nur noch Template Engines, fast immer Smarty - was daran liegt, dass ich PHP und HTML voneinander komplett trennen will. Für kleinere Sachen ist das absolut überdimensioniert. In der Praxis hat es sich jedoch bewährt: Der Designer kann in Ruhe alles designen und wir können für jeden Kunden schnell und individuell den Output anpassen ohne im Quellcode rumzufummeln - sehr hilfreich bei Updates. Einfach die php Datei überschreiben, fertig. Würde das php im HTML eingebunden werden, wäre jedes Updates ziemlicher Aufwand. Also statt php in HTML einzubinden, binde ich eher das HTML in PHP ein :)

Variableninitialisierung:

Ist der große Schwachpunkt von php und meist die Ursache viele Fehler. Würde mir da auch wünschen, dass Strongtyping endlich Einzug erhält. (Da wäre vllt. auch mal Überladen von Methoden drin). Da aber ohnehin geprüft werden muss, ob eine Variable valide ist (gerade wenn man OO programmiert und da mehr als ein Programmierer dranhängt) - ist das erstmal nicht soooo dramatisch. Besser wäre es trotzdem.

Objektorientierung:

Es ist besser im Sinne der Wiederverwendbarkeit. Viele Dinge kehren halt doch immer wieder und da möchte ich nicht jedes Mal den Code copy & pasten. Positiver Nebeneffekt: Einen Fehler kann ich zentral an einer Stelle korrigieren und muss nicht in vielen Dateien herumhantieren. Durch die Kapselung verhindere Seiteneffekte (ups, habe ich etwa in Zeile 4436 die Variablle $sonstwie überschrieben die in Zeile 345 initaliesiert worden ist und dooferweise in Zeile 8989 noch gebraucht wird? Bei meinem ersten roßen Projekt mit php war das _die_ Fehlerquelle #1). Es gibt nicht umsonst soviele Wrapper Klassen für alle möglichen Dinge in PHP. Weiterer Vorteil: Mehrere Programmierer können am gleichen Projekt arbeiten ohne sich ständig in die Quere zu kommen. Außerdem macht das den eigentlichen Quellcode wesentlich übersichtlicher.


Includes/Requires:
Vorteil durch Objektorientierung: Man kann dynamisch nur die Datein laden, welche auch gebraucht werden: http://php.net/manual/de/language.oop5.autoload.php Außerdem kann man schön mit Exceptions um sich werden :) Error Handling at its best


Settings und Lokalisierung:
Viele Möglichkeiten: Für Lokalisierung eignen sich entweder: Templates oder halt Metadateien, welche die entsprechenden String beinhalten. Wird afaik quasi überall so gehandhabt (auch bei Desktopanwendungen). Persistente oder häufig genutzte Settings wie Zugangsdaten für die SQL DB binde ich meistens auch per require ein. Für alles andere: Tabelle in der DB, welche die Settings beinhalten. Das sollte man aus Performancegründen aber auch nur so machen, wenn die Settings a) nicht so häufig gebraucht werden und b) eine Änderung zumindest geplant ist. Diese Änderungen können dann in der DB durchgeführt werden ohne an den php Dateien zu werkeln.


Kleinere Sachen mache ich meistens auch quick'n'dirty.