Kommentieren...

Über Kommentierung von SourceCode kann man ja trefflich streiten. Ich persönlich bin der Meinung dass es sinnvolle Kommentare gibt (da weiche ich schon zu den Hardlinern ab, die der Meinung sind Code ist Code ist Selbsterklärend). Kommentare sollten dann platziert werden, wenn beim Implementieren etwas Hirnschmalz gefordert war - oder wenn die Gefahr hoch ist, dass man es in ein einem halben Jahr vergessen hat um was es im einzelnen ging. 

Beispiel: Annahmen oder Voraussetzungen: ein Algorithmus der voraussetzt, dass eine Liste aus einem DB ResultSet bereits sortiert und gefiltert vorliegt - was ggf durch ein DB Statement schon passiert, ist durchaus einen Kommentar wert. 

Getter und Setter *seufz* müssen nicht kommentiert werden.

Hier mal ein Real World Beispiele

// write HistorieLauf
writeHistorieLauf();

oder
// init Batchlauf record
initBatchlauf();

oder


commit(); // commit work



Sind jetzt nicht gerade Kommentare die das Verständnis fördern.


Mein persönlicher Favorit:

// Hallo Co-Entwickler! Dieser
// Code mag umständlich sein,
// dient aber mir zum fachlichen
// Verständnis! Bitte so
// lassen...

OMG, ich habe grade einen Alptraum aus dem mich keiner weckt:

  

Bei einer Software eines großen magenta Telekommunikationsanbieter, die bei einem großen Stuttgarter Automobilkonzern im 21 Jahrhundert produktiv eingesetzt wird, habe ich ein Musterbeispiel für schlechtes DB Design gesehen. (Sollte ein Student sowas in irgendeiner DB Klausur abgeben, wird er sofort exmatrikuliert mit Empfehlung für die Baumschule).

  
Es geht um Dokumente die mehrsprachig in einer DB abgelegt werden: Titel, Name, Dateigröße, Abschnitt (=logische Gruppierung), Abschnittname etc.

• Dokumente haben pro Sprache eine Bezeichnung und einen Dateinamen.
• Dokumente haben eine Größe
• Dokumente haben ein Erstellungsdatum
• Dokumente können gelöscht sein, aber müssen in der DB bleiben
• Es gibt verschiednene Abschnitte (aka Module)
• Dokumente werden Abschnitten zugeordnet
• Module haben pro Sprache genau eine Bezeichnung.

Das "Design" verstößt schon gegen die 1NF (!!!) und sieht so aus: Es wird alles in eine Tabelle geklatscht.

ID,  INTEGER
LANGUAGE,  CHAR
MODULID, INTEGER
DOC_BEZEICHNUNG, VARCHAR
DOC_FILENAME, VARCHAR
DOC_TYPE, CHAR
DOC_DATE, DATE
DOC_SIZE, CHAR
MODUL_BEZEICHNUNG, VARCHAR
GELOESCHT, CHAR
DATA, BLOB

Leute das macht jeder Schüler besser!!

Der absolute Schenkelklopfer, ist die DOC_SIZE - schaut euch mal den Datentyp an - muahaha - als CHAR. Und es kommt noch besser, der Inhalt sieht z.B. so aus "884 kB", die haben tatsächlich auch noch die Einheit mit in der gleichen Zelle abgelegt *popcornhol*. 1NF verletzt, dass muss man erstmal hinkriegen.

Ach ja 2NF ist natürlich auch gleich verletzt, Schlüssel der Tabelle ist nämlich ID + Sprache. Modulname + Bezeichnung werden redundant gehalten *gnihihii*.

 

Bin mal weg, Kotztüten sins alle...

Jmockit und Jacoco

Ich habe mir neulich mal JMockit genauer angeschaut. Jmockit erleichtert es SEHR Mockobjekte zu schreiben um die Interaktion zwischen Objekten zu testen.

Vorteile: Strikte Trennung von Code under Test vom Testcode und eine wahnsinns Flexibilität. Man muss die zu testenden Klassen nicht anpassen und schafft keinerlei Abhängigkeit! JMockit leitet die Calls auf getestete Klassen mittels Bytecodeinstrumentation um, und mockt diese. Man kann relativ elegant beliebige Klassen (auch nur teilweise) mocken und deren Rückgabewerte definieren.

Jetzt hatten wir hier ein Problem, weil Jacoco eingesetzt wird um die Test-Coverage zu ermitteln - also zwei Programme die den Bytecode instrumentieren. Mein Bugreport (zuerst bei Jmockit eingekippt) wurde mittlerweile sogar von Eclemma/Jacoco behoben.