Das haengt vielleicht mit den Anordnungs- und Einrueckungsvorlieben, die man so hat, zusammen. Ich hab' z.B. die Tendenz, wiederkehrende Elemente in PHP-Funktionen auszulagern. Deren Inhalt wird dann aber nicht so weit eingerueckt, wie er's an den entsprechenden Stellen im HTML-Code eigentlich sein sollte -- falls jene in dieser Hinsicht ueberhaupt konsistent sind.
Aber ich geb' zu, dass ich, was den "ausgelieferten" HTML-Code betrifft, auch ziemlich wenig Ehrgeiz habe, ihn moeglichst huebsch zu formatieren. Die Zielgruppe ist da ja ziemlich klein und rechtfertigt deshalb fuer mich den zusaetzlichen Aufwand -- sei er auch gering -- nicht.
Und wer unbedingt wissen will, zu welcher Pseudoklasse der dritte Link im zweiten div von rechts gehoert, der kann ja -- wie gesagt -- einmal OmniWeb oder einen vergleichbaren Editor drueberrauschen lassen.
Das ist durchaus richtig, aber ich habe die Erfahrung gemacht, dass Seiten, die so entstehen, wie Du oben beschrieben hast, sich leichter und treffsicherer nach Fehlern durchsuchen lassen und das ganz ohne zusätzliche Werkzeuge. Natürlich ist es sehr praktisch, mit Firebug, Omniweb, XyleScope, oder gleich Safari 3 (Inspect Element) das DOM zu durchforsten aber ich habe mir angewöhnt, die Ausgabe von Tabulatoren bei der HTML-Ausgabe gleich mitzuprogrammieren.
Zum Beispiel: Es soll eine neue WebSite für den Knopflochbohrer um die Ecke erstellt werden. Die Struktur der WebSite ist so definiert, dass sie sich mit einem Baum vergleichen lässt, was bedeutet, dass sich eine Aufzählungsliste ('<ul>') oder eine Definitionsliste ('dl') geradezu anbietet, um über die Struktur zu iterieren.
Zeit, das Eingabefenster rechts unten mit dem Mauszeiger größer zu ziehen. Ah, was für ein Genuss; jedoch weiter im Text.
Angenommen, ich erhalte die Navigationsstruktur als Ergebnis einer Datenbankabfrage in Form eines assoziativen Arrays (»Hash Table«). Iteriere ich lieblos über die Ergebnisliste sieht das im schlimmeren Fall wohl mehr oder weniger so aus:
Code:
if ($resultat = gibHerDieStruktur($verbindung)) {
echo "<ul>";
while ($details = mysql_fetch_assoc($resultat)) {
echo "<li>" . htmlentities($details['kapitelbezeichnung']) . "</li>";
}
echo "</ul>";
}
Das Ergebnis dieser Programmierung bedeutet wenig Zeitverbrauch bei maximal undurchsichtigem HTML-Code:
Code:
<ul><li>Die Firma</li><li>Unsere Produkte</li><li>Service</li><li>Kontakt</li></ul>
Nicht wirklich schön, nach meinem Geschmack (aber möglicherweise nur mein Geschmack). Ich kann jedem empfehlen, ein wenig anspruchsvoller zu sein:
Code:
if ($resultat = gibHerDieStruktur($verbindung)) {
echo "<ul>\n"; // Ein Zeilenumbruch mehr ist hilfreich;
while ($details = mysql_fetch_assoc($resultat)) {
printf("\t<li><a href=\"%1\$s?seiten_id=%2\$u\" title=\"%3\$s\">%3\$s</a></li>\n"
, $_SERVER['PHP_SELF']
, $details['id']
, stripslashes(htmlentities($detail['kapitelbezeichnung']))
);
}
echo "</ul>\n";
}
Und schon wird's entsprechend übersichtlicher, denn dafür ist das mit den Einrückungen ja gedacht
Die Code-Beispiele sind stark vereinfacht und einfach mal so runtergetippt.
In Skript-Sprachen wie PHP, wo die Ausgabe direkt im Code erzeugt wird, ist es besonders lohnenswert, sich bestimmte Konventionen selbst zurecht zu legen. Dabei mag das obere oder das untere Beispiel der eigenen Konvention entsprechen.
Später wird man dann dazu übergehen, die Ausgaben zu »kapseln« und von Ausgabemodulen verarbeiten zu lassen, anstatt schlicht »echo "<ul>"« zu verwenden, was dann natürlich immer mehr in Richtung der Objektorientierung weist, aber das ist ein ganz anderes Thema.
Wichtig ist nur (auch private Projekte) so zu bauen, dass man sich selbst wieder erkennt, und gleichzeitig den Code nach drei Monaten noch lesen kann. Bei Projekten aus meiner Anfangsphase bin ich selbst rettungslos verloren, da ich hier auf Kommentare und jegliche Struktur verzichtet habe. Damit ist aber auch die Denkleistung im Orkus.
