Coderichtlinien bewerten

[Vinzenz Mai]

Hallo

In einer eigenen Zeile will ich es haben, damit man meinen Namen einfach leichter finden kann.

Mich persönlich hat es durchaus gestört. Ich habe mein Browserfenster kleiner und größer gemacht, es war immer in einer eigenen Zeile - ohne dass ich dafür einen bestimmten Grund sah. In Deinem Satz fehlt übrigens auch die Interpunktion.

<address> wäre geeignet, zwänge Dich jedoch dazu, zwei <p>-Elemente zu verwenden. Meiner Meinung nach wäre dies die passendere Lösung und ein gutes Beispiel für den sinnvollen Einsatz dieses Elementes. *g*

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.

Ich habe kein Problem damit, Schwachstellen klar und deutlich anzusprechen, dennoch bin ich ein grundsätzlicher Anhänger einer positiven Darstellung. Mir stößt Dein Stil unangenehm auf. Ich wäre durch Deine Einleitung negativ gegenüber dem Rest eingestellt. Ich wäre motiviert, Dich bei Fehlern und Inkonsistenzen zu ertappen. Bei mir hätte Dein Dokument sein sehr sinnvolles Ziel verfehlt, was schade wäre. Wer mit dem Herzen dabei ist, wer von einer Sache überzeugt ist, dem fällt es leicht, solche Richtlinien zu befolgen und konsequent einzuhalten. Wenn Dein Stil das bei Deiner Zielgruppe dieses Ziel erreicht, dann ist das in Ordnung.

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

Ich auch nicht, ich muss diesen noch ausnehmen.

Dann hat mein Beitrag bereits etwas bewirkt *freu*

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.

Nein. Auch dann nicht:

"Wenn eine Funktion nur eine Varibale benötigt, dann muss diese $var heißen."

Wäre dies Deiner Meinung nach sinnvoll? Bestimmt nicht. Warum bei Datenbankzugriffen. Du widersprichst Dir selbst:

<zitat>Variablen müssen sinnvoll benannt werden</zitat>

Es ist einfacher die Anweisung zu geben "Schau in $sql nach" als "schau in $ja_wie_hies_sie_nochmal nach".

Wie kommst Du auf diese seltsame Idee?

<zitat>Variablen müssen sinnvoll benannt werden</zitat>

Und das sollte auch für diese Gruppe gelten. Möglicherweise möchtest Du spezielle Präfixe für diese Variablen vorschreiben?

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

Ich werde nach deinen Postings suchen.

Das ist eine gute Idee :-)

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

Danke.

Inzwischen nicht mehr wegen Whitespaces, nur noch (möglicherweise) wegen eines Feldnamens, aber sei bitte konsequent.

<zitat>
$sql = 'SELECT t.vorname,t.nachname,v.datum ';
// Die betroffenen Tabellen
$sql.= ' FROM teilnehmer t, veranstaltung v ';
// Zuerst die Joins und dann alle weitern Bedingungen
$sql.= ' WHERE t.id=v.teilnehmer ';
$sql.= ' AND v.name LIKE 'M%'';
</zitat>

Fragen:
    Warum trennst Du die Feldnamen nicht durch Leerzeichen?
    Warum gönnst Du Feldnamen und Tabellennamen nicht eigene Zeilen?
    Warum verwendest Du keine explizite JOIN-Syntax?
    Warum trennst Du nicht Operator und Operand?

Ich ändere schrittweise:

$sqlBenutzerDaten = 'SELECT' . "\n"
    . '    t.vorname,' . "\n"
    . '    t.nachname,' . "\n"
    . '    v.datum' . "\n"
    . '-- Die betroffenen Tabellen' . "\n"
    . 'FROM teilnehmer t' . "\n"
    . '-- Zuerst die Joins' . "\n"
    . 'INNER JOIN veranstaltung v' . "\n"
    . '    ON t.id = v.teilnehmer  -- Überdenke die Spaltennamen :-)' . "\n"
    . 'WHERE vname LIKE 'M%'     -- Ich mag keine Backslashitis' . "\n";

oder vielleicht auch (mit Verstoß gegen Deine Regeln)

$sqlBenutzerDaten =
'SELECT
    t.vorname,       -- hier mit Tabulator :-)
    t.nachname,      -- auch der Kommentar mit Tabulator eingerückt
    v.datum          -- außer hier im Antwortfenster ;-)
    FROM teilnehmer t
    INNER JOIN veranstaltung v       -- Zuerst die Joins
        ON t.id = v.teilnehmer       -- Trenne Operatoren und Operanden ;-)
    WHERE t.vorname LIKE 'V%'      -- Wenn es unbedingt sein muss :-(
                                     -- Fällt Dir meine Korrektur auf?
        AND t.nachname LIKE 'M%'   -- Aber ist das wirklich lesbar?';

Lesbarer Code ist wartbarer Code und damit effizienter als unlesbarer Code, der das gleiche macht. Fehler in SQL-Statements zu finden, ist oftmals mühsam, oft fehlt nur ein Whitespace, manchmal nur ein einfaches Anführungszeichen.

Wende daher auf generierte Statements vergleichbare Regeln an wie auf geschriebenen Code.

Freundliche Grüße

Vinzenz