Codeoptimierung:Code-Smells

[cyro]

Na ja, dein Argument ist jetzt aber: „Es ist sinnfrei, auf die Korrektheit von Schnittstellenrückgaben zu achten, denn mich hält nichts davon ab, später im Code einen Tippfehler in einem Variablennamen zu haben.“

Nein, das ist nicht mein Argument.

Aber wenn man in einem Wikiartikel argumentiert, dann sollten die Argumente schon der Wahrheit entsprechen. Und das Folgefehler Argument hat halt nichts mit dem SELECT * zu tun und ist daher unangebracht. Ich denke ich hab das jetzt mehrfach schlüssig dargestellt.

[tr0y]

* birgt aber die "Spekulative Allgemeinheit", man darf sich ruhig auf Folgefehler beziehen, wenn man alles bestellt, aber das was man im Endeffekt brauch nicht dabei sein kann. Genau genommen sollte die Fehlerquelle eher das Query sein, das Felder bestellt die nicht da sind, als das ein folgender Array-Zugriff auf ein Datenfeld zugreift, das garnicht mitkommt. Bei Query-Fehler, ist mitunter bei den neueren Datenbank-Interfaces auch besseres Fehler-Handling an Bord.

[mermshaus]

(Sorry, das ist x-fach dasselbe, aber ich habe keine Lust, das noch mal pointierter zu formulieren.)

Nein, das ist nicht mein Argument.

Aber wenn man in einem Wikiartikel argumentiert, dann sollten die Argumente schon der Wahrheit entsprechen. Und das Folgefehler Argument hat halt nichts mit dem SELECT * zu tun und ist daher unangebracht. Ich denke ich hab das jetzt mehrfach schlüssig dargestellt.

Die Folgefehler entstehen aber doch dadurch, dass SELECT * erst mal alles durchlässt und so unter Umständen Felder nicht gesetzt sind, die der Programmierer erwartet. Würden statt SELECT * alle Felder sauber in der Query aufgeführt, würde bei nachträglichen Änderungen am Datenbankschema bereits die Query selbst fehlschlagen und es gäbe erst mal keine Folgefehler.

Wenn man dein Beispiel hernimmt:

function getUser($id) {
  // connect, variablenbehandlung, etc. 

  $ress = mysql_query("SELECT `Id` , `Name` FROM Personen WHERE id=$id");
  if($data = mysql_fetch_assoc($ress)) {
    return $data;
  }
  return false;
} 

Wenn du in der Datenbank die Spalte „Name“ in „Nickname“ umbenennst, wird die Query sofort fehlschlagen.

Darauf würdest du wieder sagen, dass es dann genauso Folgefehler geben könnte, denn der Programmierer könnte die Felder in der Query ändern, aber im nachfolgenden Code weiterhin falsche Feldnamen verwenden.

Und darauf würde ich wieder sagen, dass so was in der Programmierung nie und bei gar nichts auszuschließen ist, was das meines Erachtens zu einem etwas müßigen Argument macht.

Für mich steht zumindest fest, dass bei Abfragen ohne SELECT * ein weiterer Korrektheits-Check durchgeführt wird, der bei Abfragen mit SELECT * nicht durchgeführt wird.

Ich zitiere noch mal den Abschnitt aus dem Wiki-Artikel:

Zudem sagt das Statement nichts darüber aus, welche Werte es liefert. Kritisch wird es, wenn sich die Tabellenstruktur ändert - Folgefehler (Zugriff auf nicht mehr existente Feldnamen) oder das Auslesen von unnützen Daten (Text, Blob) kann die Folge der *-Konvention sein.

Das meint eben einfach, dass eine Query mit SELECT * bei Änderungen an der Datenbank nicht fehlschlagen würde (was zu indirekten Folgefehlern führt), eine Query mit Auflistung der gewünschten Felder dagegen schon.

Das ist ein zusätzlicher Nachteil von SELECT * und das macht Folgefehler wahrscheinlicher, weil ein zusätzlicher Korrektheits-Check fehlt. Wie wesentlich das ist, will ich nicht beurteilen, aber der Abschnitt ist so, wie er im Wiki steht, nicht falsch.

Vielleicht noch gerade zu einem Absatz aus meinem vorherigen Post:

Der Wiki-Artikel ist sicherlich nicht unbedingt für Profi-Entwickler gedacht, die ihren Code „vollständig“ mit Unit-Tests abgedeckt haben und die dazu noch eine Nachricht erhalten, falls in einer Anwendung mal irgendwo eine PHP Notice geworfen wird.

Damit will ich sagen, dass es Leute, die SELECT * nutzen, unter Umständen überhaupt nicht merken, dass sie vergessen haben, ihren Code oder Teile ihres Codes an ein verändertes Datenbankschema anzupassen. Entweder haben sie überhaupt keine PHP-Notices aktiviert oder sie haben PHP-Notices zumindest auf dem Produktivsystem nicht aktiviert und testen lokal nicht jeden Aspekt des Codes vor Veröffentlichung. Das halte ich beides nicht für zu unwahrscheinlich.

Wenn aber bereits die Query fehlschlägt, fällt das auf oder macht zumindest das vollständige Durchlaufen des Codes unmöglich. Dann wird nicht vergessen, die Mehrwertsteuer hinzuzurechnen oder dergleichen.

$price += $price * $row['mwst']; 

Es sei denn, der Programmierer ändert die Feldnamen in der Query, übersieht aber das 'mwst' an dieser Stelle. Dagegen ist aber wie gesagt überhaupt kein Kraut gewachsen und das ist vor allem nichts, was den zusätzlichen Nachteil von SELECT * aufhebt.

[Asterixus]

Unabhängig von Performance muss ich anmerken, dass nach der Codeübernahme einer anderen Person oder generell nach einiger Zeit Code mit select * total undurchsichtig ist. Es ist viel angenehmer, die Felder aufzulisten, da man somit sofort den Überblick hat, über was es gibt und was benötigt wird.
Ich habe mich vor ein paar Tagen noch darüber aufgeregt, als ich das Projekt eines verschollenen Programmierers übernehmen musste.

Tu deinem zukünftigen Dir oder einem potentiellen nächsten Programmierer den Gefallen und sorge dafür, dass dein Code klar ist.