Archiv der Kategorie: MySQL

Teil 2: Clean Code – richtige und falsche Kommentare

vom by
Kommentar

Nach dem Buch (Kapitel 4):  “Clean Code – Refactoring, Patterns, Testen und Techniken für sauberen Code” von Robert C. Martin.

“Kommentieren Sie schlechten Code nicht – schreiben Sie ihn um.”

(Brian W. Kernighan und P.J. Plaugher)

 

Kommentare können beides sein, hilfreich und hinderlich:

  • hinderlich, wenn Sie überholt sind und Fehlinformationen liefern
  • störend, wenn Sie zu lang sind und unnötig
  • hilfreich, wenn Sie wohlplatziert sind

Der Einsatz von Kommentaren “soll unsere Unfähigkeit ausgleich, uns in unserem Code klar auszudrücken”(S.85). Bevor man einem Kommentar schreibt, sollte man vorher überlegen, ob der Code nicht noch ausdrucksstarker geschrieben werden könnte.

weiterlesen… “Teil 2: Clean Code – richtige und falsche Kommentare” »

Verlinken Sie sich!

Teil 1: Clean Code – Regeln für guten, sauberen Code

vom by
Kommentar

Sauberen und leicht verständlichen Code zu schreiben ist das höchste Ziel in einem guten IT-Projet. Vieles hängt davon ab:

  • Wartbarkeit
  • Einarbeitungszeit für andere Programmierer, versteht man schnell, was einzelne Funktionen erledigen
  • Robustheit bei Änderungen
  • Testbarkeit, fällt alles zusammen, bei kleinen Änderungen, können schnell stabile Updates bereitgestellt werden
  • Popularität bei anderen Programmierern z.B: bei Open Source Projekten, als negative Beispiel sei XT-Commerce genannt

Das sehr zu empfehlende Standardwerk zu dem Thema ist “Clean Code – Refactoring, Patterns, Testen und Techniken für sauberen Code” von Robert C. Martin. In diesem Artikel werden Kapitel 1 bis 3 behandelt.

Aussagekräftige Namen

Der Namen einer Variable, Funktion oder Klasse sollte sofort erklären, warum Sie existiert, was sie tut und wie sie benutzt wird. Wenn eine Variable einen Kommentar benötigt, drückt Sie ihren Zweck nicht aus.

Bsp:

int d //Anzahl vergangener Tage
besser ist:
int daysSinceCreation;

Aussprechbare Namen verwenden

Keine Konstrukte mit unklaren Abkürzungen wie: int daSiCre anstatt von daysSinceCreation.

Suchbare Namen verwenden

Moderne IDEs machen das Suchen einfach, aber es nützt nichts, wenn man nach dem Buchstaben e einer Laufvariable suchen muss und von Ergebnissen überschwemmt wird.

Variablen Namen mit einem Buchstaben sind nur als lokale Variablen in kurzen Methoden zu verwenden.

weiterlesen… “Teil 1: Clean Code – Regeln für guten, sauberen Code” »

Verlinken Sie sich!

Installation Eclipse PHP PDT Plugin unter Windows7 Tutorial

vom by
Kommentar

Zur professionellen Entwicklung gehört auch eine gute IDE. Ich verwende dafür normalerweise Netbeans, aber viele Entwickler empfehlen das kostenpflichtige Zend Studio bzw. das ähnliche aber kostenlose Plugin für Eclipse von Zend: das PDT-Plugin.

Die Installation von Eclipse incl. Plugin kann sehr einfach im “All-in-one-Package” durchgeführt werden.

weiterlesen… “Installation Eclipse PHP PDT Plugin unter Windows7 Tutorial” »

Verlinken Sie sich!

MySQL Umlaute/Sonderzeichen in der DB fixen UTF-8

vom by
2

Jeder kennt das Problem, aus irgendeinem Grund wurden Wörter in der falschen Kodierung in die Datenbank geschrieben. Wenn das passiert ist, kann man daran erkennen, dass sich Zeichen wie diese untergemischt haben:

‘¦, ‘¨, ‘?, ‘´, ‘¸, ‘À, ‘Á, ‘Â, ‘Ã, ‘Ä, ‘Ã…, ‘Æ, ‘Ç, ‘È, ‘É, ‘Ê, ‘Ë, ‘ÃŒ, ‘Í, ‘ÃŽ, ‘Ï, ‘Ñ, ‘Ã’, ‘Ó, ‘Ô, ‘Õ, ‘Ö, ‘Ø, ‘Ù, ‘Ú, ‘Û, ‘Ãœ, ‘Ý, ‘Þ, ‘ß, ‘à, ‘á, ‘â, ‘ã, ‘ä, ‘Ã¥, ‘æ, ‘ç, ‘è, ‘é, ‘ê, ‘ë, ‘ì, ‘í, ‘î, ‘ï, ‘ð, ‘ñ, ‘ò, ‘ó, ‘ô, ‘õ, ‘ö, ‘ø, ‘ù, ‘ú, ‘û, ‘ý, ‘þ, ‘ÿ

Das Problem ist, dass diese Zeichen nicht utf8 kodiert worden sind, aber in utf8 abgespeichert worden sind, weil die DB Spalte so definiert worden ist (Kolation: utf8_general z.B:). weiterlesen… “MySQL Umlaute/Sonderzeichen in der DB fixen UTF-8” »

Verlinken Sie sich!

MySQL reservierte Bezeichner und Release

vom by
Kommentar

Gerade habe ich an dem Problem gehangen, dass ich mit Doctrine eine neue Spalte namens “release” füllen wollte. Mit Release wart das Release-Datum von CDs gemeint. Es kam die Standard Fehlermeldung von MySQL, das ein  Fehler bei release war.

$products->release = 2003;

Natürlich habe ich es auf Doctrine geschoben, weil da oft solch ein komisches Zeug passiert. Komisch war, dass die Fehlermdlung nicht auftrat bei:

$products->release = NULL;

Das gab mir schwer zu denken und führte mich auf die falsche Fährte in Richtung, dass der Wertebereich nicht passte.

Die Lösung war ganz einfach: Das Word Release gehört zu den reservierten Wörtern in MySQL, was ich nicht wusste. Einen Überblick gibt es hier.

Die Lösung war also, den Spalte umzubennen in product_release, damit funktioniert es dann:

$products->product_release = 2003;

Was genau der release-Befehl in MySQL macht, konnt ich leider nicht herausfinden, ich freue mich auf Beiträge darüber.

Verlinken Sie sich!

Strings speichern in MySQL und Sicherheit

vom by
1

Um einen String abzuspeichern mit unbekanntem Inhalt, sollte immer die PHP Funktion mysql_real_escape_string verwendet werden:

$mystring = mysql_real_escape_string($mystring );

Damit werden bösartige Strings entschärft, mit denen großer Schaden angerichtet werden kann wie:

$string = "1';DELETE FROM table WHERE 1;#";
$sql = "SELECT * FROM table WHERE id = '$string' ";

Dies kann durch die Verwendung der Funktion verhindert werden.

 

 

Verlinken Sie sich!

MySQL SELECT Daten, die nicht älter als x Tage/Stunden/Minuten sind

vom by
2

Wenn man eine Spalte vom Typ timestamp hat und nur Daten eines bestimmten Alters selektieren will,  kann man dies in MySQL tun mit der DATE_SUB Funktion:

SELECT * FROM ... WHERE  timestamp > TIMESTAMP(DATE_SUB(NOW(), INTERVAL 1 hour))

Damit werden nur Daten selektiert, die nicht älter als eine Stunde sind. Das gleiche funktioniert bspw. auch mit Tagen -> day und  Minuten->minute.

Eine andere Möglichkeit wäre, PHP dafür zu benutzen, aber aus Performance Gründen sollte man immer MySQL vorziehen.

Verlinken Sie sich!

MySQL Duplicate entry ’1′ for key ‘PRIMARY’

vom by
Kommentar

Wenn man eine Fehlermeldung bekommt wie

Duplicate entry '1' for key 'PRIMARY'

Dann sollte man den Eintrag entweder mit UPDATE (beste Variante)

INSERT INTO table (a,b,c) VALUES (1,2,3)
  ON DUPLICATE KEY UPDATE c=c+1;

oder einfach nichts verändern in der Datenbank entweder mit

INSERT IGNORE INTO table (a,b,c) VALUES (1,2,3)

Wobei hier auch mögliche Fehlermedlungen unterdrückt werden. Achtung!

Verlinken Sie sich!

MySQL speichert immer 2147483647 ab

vom by
Kommentar

Die Lösung ist ganz einfach, die 2147483647 ist der maximale Wert einer int-Variablen in MySQL (231 − 1). Wenn versucht wird in eine int-Spalte einen größeren Wert zu schreiben, so speichert MySQL immer dieses Wert ab, anstelle des gewünschten, größeren Wertes. Dann sollte man den Datentyp bigint nehmen, der Zahlen bis 9223372036854775807  zulässt (signed) oder auf unsigned (nur positive Werte, reicht bis 4294967295) umstellen.

Verlinken Sie sich!