Coderichtlinien bewerten

[Severin Kacianka]

Hallo Vinzenz,

Und genau aus diesem Grund sollte sich _Dein_ Dokument an _Deine_ eigenen Coderichtlinien halten, um Deine Richtlinien vorbildlich zu demonstrieren. Bitte überprüfe deswegen Dein eigenes Dokument auf die Einhaltung Deiner Vorgaben. Schau' Dir z.B. die unlogische Verwendung von <br /> im Punkt 0.2 an. Ich weiß nicht, warum Du Deinen Namen und E-Mailadresse in eine eigene Zeile gesetzt hast. <br /> solltest Du hier einfach weglassen oder wenn Du eine eigene Zeile haben willst, durch angemessenere Auszeichnung ersetzen.

Das <br /> _nach_ Name und E-Mail ist da noch eher unnötig, das davor finde ich aber so passend wie selten. Ich will nichts anderes erreichen, als dass mein Name nicht in der selben Zeile wie der vorherige Satz ist. Wie soll ich soetwas auszeichenen? Es ist kein Absatz. Ein Absatz ist (IMHO) länger als ein paar Worte (oder der einzige Satz unter einer Überschrift) und ist vom verhergehenden Absatz getrennt. Das trifft nicht zu. Für mich gehört mein Name und E-Mail sematisch zu diesem einen Absatz.
In einer eigenen Zeile will ich es haben, damit man meinen Namen einfach leichter finden kann.

Deine Einleitung könnte positiver ausfallen. Fällt Dir wirklich nichts ein, warum Coderichtlinien sinnvoll sind.

Diese negative Art zu schreiben, ist meine Art Liebe zu zeigen. Ich halte nichts davon etwas in den Himmel zu loben, sonder nimm den Kritikern lieber  humorvoll den Wind aus den Segeln.
Wenn ich Coderichtlinien nicht für sinnvoll halten würde, hätte ich wohl kaum dieses Dokument geschrieben und alle im Team davon überzeugt es zu versuchen.

"Tags sind klein zu schreiben, Attributwerte grundsätzlich in Anführungszeichen (welche eigentlich) einzuschließen. Ist es eine Einführung in XHTML? Nein. Willst Du auch nicht. Gib' dem Absatz eine neue, passendere Überschrift.

Doch es ist eine Art Crashkurs. Die Zielgruppe hat noch nie XHTML geschrieben oder gesehen und ich möchte sie ein wenig darauf vorbreiten. Es wird so oder so noch jede Menge persöhnliche Überzeugungsarbeit nötig sein.

Bei PHP hast Du ja herzlich wenig geschrieben.

Weil ich noch nicht so ganz weiß, was alles unklar werden könnte. Ich habe versucht alle möglichen Probleme schon jetzt abzudecken, werde die Richtlinien aber wohl noch laufend erweitern müssen. In PHP gibt es wenig Erfahrungen in unserer Zusammenarbeit. Bis jetzt war immer jeder nur für "seinen" Teil zuständig, und musste sich oft lang in das "Revier" des anderen einlesen.

Nicht sinnvoll ist dies _meiner Meinung nach_ beim Inkrement- und Dekrementoperator.

Ich auch nicht, ich muss diesen noch ausnehmen.

SQL-Statements durchzunummerieren ist genauso unsinnig wie die Verwendung von Variablen der Form a1, a2, a3, a4 bis a378 für alle Variablen einer Funktion oder einer Klasse.

Jaein. Wenn es in der Regel nicht mehr als eine Abfrage pro Programm gibt bleibt es so einfach. Es ist einfacher die Anweisung zu geben "Schau in $sql nach" als "schau in $ja_wie_hies_sie_nochmal nach".

Selbiges gilt auch für $con,$result und $query. Sie werden in diesem Projekt eine eindeutige Sematik haben.

Die Formatierung Deiner SQL-Statements ist ebenfalls verbesserungswürdig.

Ich werde nach deinen Postings suchen.

Dein Statement selbst im Beispiel wird übrigens wegen Syntaxfehler scheitern.

Danke.

Sieh' bitte mein Posting als konstruktive Kritik. Du hast einen guten ersten Ansatz, auf dem Du aufbauen kannst.

Danke :-)

Gruß,
Severin