Zum SelfHTML-Wiki

[Raketenqualitätskontrolle]

Ich schrieb:

Viel mehr Sorge bereitet aber die Frage, warum ich das wohl übersehen habe...

Das habe ich zu konkretisieren. Fangen wir an.

Der Verein sollte wohl einige Regelungen, z.B.

• zur Benennung von Variablen, Konstanten, Klassen, Objekten, Funktionen
• zur Formatierung des Codes

treffen. Übrigens nicht nur für den PHP-Teil.

Ich nehm mal das obige:

if (!isset($_COOKIE[COOKIE_NAME])) {
    $aufruf = 1;
} else {
    $aufruf = $_COOKIE[COOKIE_NAME] + 1;
}

Als „unschön“ markiere ich, dass 'COOKIE_NAME'. Große Buchstaben und Unterstriche als Trenner sind Merkmale von Namen für Konstanten und Variablen, die von PHP selbst belegt werden. Man muss ja nicht gleich die komplette ungarische Notation verwenden: Aber, wie ich das sehe, wäre hier 'CookieName' angenehmer zu lesen und auf den ersten Blick erkennbar, was das denn wohl sei.

Ich benutze z.B. bei neuen Projekten seit einiger Zeit den ersten großen Buchstabe für eigene Konstanten und Klassen, ersten kleinen Buchstabe für Funktionen und Variablen; CamelCase als Merkmal für zusammengesetzte eigene Namen, Plural für Arrays oder andere Listen, $item für den aktuellen Wert in etwas wie foreach(), jedoch stets $row für eine Zeile und auch sonst gern die Bezeichner, welche PHP.net in der Dokumentation verwendet. Was für das Wiki vorgeschlagen oder vorgeschrieben wird ist aber Ansichtssache.

Auch könnte man vorschreiben/empfehlen, bei Arumentlistenbegrenzern (,), Listenbegrenzern [, ], meinetwegen auch {, } zwischen diesen und dem Inhalt ein Leerzeichen zu setzen:

if ( ! isset( $_COOKIE[ CookieName ] ) ) {

Natürlich auch hinter (und vor) Kommas in Listen und allen Arten von Operatoren.

Das wäre nach meiner Ansicht, die auf einem sich schleichend verschlechterndem Sehvermögen im Kurzstreckenbetrieb beruht, viel besser lesbar.

Dann hab ich noch gesehen, dass die Stellung der Blockbegrenzer {, } bei den Autoren und also Einträgen variiert:

derEine( 'notiert', 'so' ) {

}

derAndere( 'notiert', 'so' )
{

}

Was davon gewählt wird ist mir ebenso egal - aber man sollte sich einigen, denn gegenwärtig hat der im Wiki präsentierte Code eine Außenwirkung, die mit dem erhobenen Qualitätsanspruch nicht übereinstimmt.

Kommen wir zum inhaltlichen Aspekten. Wie schon von anderen erwähnt wurde werfen manche Artikel Äpfel, Eier und Rüben durcheinander, was erst die Übersicht und dann deren Sinn verwässert und offenbar sogar die Autoren auf Ab- und Umwege führt - welche durchaus mit der Threadtrift hier im Forum vergleichbar sind.

• z.B. das Dateiupload-Skript.

Darin hat, so sehe ich das, die Prüfung, ob es sich um ein Bild handelt, viel zu viel Raum. Das würde ich konsequent abtrennen und zwar einmal in „Dateiupload“ und dort z.B. die Größenbegrenzung - und wie man diese korrekt begrenzt - genauer besprechen.

Im womöglich weiteren abgegrenzten Artikel über die „generelle Behandlung von Bilddateien aus Drittquellen“ kann man dann den Dateiupload unter einmaligem Verweis auf den speziellen Artikel „einfach und kommentarlos machen“ und den Besonderheiten der Verarbeitung von Grafikdateien aus Drittquellen (e.g. APIs und „so was“) mehr Raum geben. z.B. bei der Sicherheit: Ich würde dazu neigen, jedes Bild mit den imagecreatefrom*-Funktionen aus der temporären Datei zu kopieren. Und dabei bzw. danach womöglich auch richtig zu drehen, was vor ein paar Tagen Thema war, ferner Thumbnails herzustellen und die Größe anpassen. Wobei man sich natürlich darüber unterhalten kann, ob nicht sogar das schon bei fremden Dateien problematisch ist, weil diese PHP-Funktionen durch das Unterschieben von „merkwürdigen“ Dateiinhalten angreifbar sein könnten.

Auch hier gilt: Was und wie das den Autoren nahegelegt wird ist Sache der Maintainer.