Hi!
Ich frage mal ganz ketzerisch: was möchtest du? Eine brauchbare Dokumentation oder ein wunderschönes semantisches Kunstwerk für Quelltext-Liebhaber?
Etwas dazwischen. Das Ergebnis ist für den Betrachter relevant. Wenn aber der Bearbeiter die Hände überm Kopf zusammenschlägt, kann das der nächste Grund sein, warum er an Kot statt Code ungern mitarbeitet.
Aber ich frage dich ganz ehrlich: wenn du mal wieder was bastelst und mal schnell nachsehen willst, in welcher Reihenfolge diese eine Funktion ihre Parameter noch mal erwartet: interessiert dich dann, ob die Quelle, die dir dieses Wissen liefert, einen Wahnsinns-Quelltext hat, der jede semantische Feinheit, die mit HTML möglich ist, aus dem Inhalt rauskitzelt?
In dem Fall nicht, und übertreiben liegt mir auch fern. Aber wenn ich schon Wasser predige, und auch hier im Forum die Anfänger "erziehen muss", ordentlichen und sinnvollen Code zu erzeugen, wenn er wartungsfreundlich sein soll, selbst aber Arbeit abliefere, die nach sehr viel Wein-Genuss aussieht, ist das auch nicht gerade glaubwürdigkeitsfördernd.
Aus der Forderung, der Code sollte ordentlich sein, muss man nicht ableiten, dass der Code ein l'art pour l'art sein muss.
Nein, aber wie gesagt, es muss auch kein Kot sein. Praktikabel muss es sein - (möglichst) für alle Seiten. Ich halte nichts von Extremen des Extrems willen. Ich schlug ja nicht umsonst nur die "Arme-Leute-Semantik" mit Klassen vor und keinen eigenen XML-Dialekt. Ich kann mir auch einfacher sprechende Klassennamen merken als die Sonderzeichensyntax von Wikis, die in Punkto Unfreundlichkeit der Perl-Syntax Konkurrenz machen zu wollen scheint.
Apropos: Ein Sandkasten zum gefahrlosen Probieren fehlt in deinem "Schnellrestaurant".
Lo!