Coding-Horror

…bzw. solange Du Dich von mir ableitest, machst Du was ich sage!

Ich finde, dies ist mal wieder ein wunderschönes Beispiel dafür, wie Objektorientierung nicht funktioniert! Gefunden von meinem Kollegen in freier Wildbahn (Namen wurden von der Redaktion geändert :) )

Heute ist mir bei einem Code-Review wieder ein kleines Schmankerl unter die Augen gekommen.
Wie immer reduziere ich es auf das Wesentliche…

Der Aufbau war wie folgt:

if( A )
{
    a;
}
if( !A )
{
    b;
}
else
{
    c;
}

Als kleine Denksportaufgabe, könnte Ihr euch ja mal RatzFatz überlegen, wie das wohl einfacher geht… Und wenn Ihr eine Idee habt, einfach den ganzen Artikel anschauen…

(weiterlesen…)

Von einem Arbeitskollegen habe ich folgendes kleines Schmuckstück erzählt bekommen, welches ich zum besseren Verständnis einfach mal in ein kleines, kurzes und zusammenhängendes Beispiel gegossen habe:

class MeineKlasse
{
public:

void set( int x )
{
if( this == NULL ) throw new ArgumentNullException();
this.x = x;
}

private: int x;
};

Zu dieser Originalität fällt mir nichts ein, was ich darauf noch sagen könnte…

Dieses Beispiel hat mir freundlicherweise ein Arbeitskollege zur Verfügung gestellt. notOK ist ein Boolean (Wahrheitswert).

if( !notOK != false ) …

Auch hier bemerkt man wieder, das Programmierer Anweisungen in Programme einbauen, die sie niemals im Alltag verwenden würden. Oder hat wirklich jemand zu seinem Kind, nachdem es hingefallen ist,  folgendes gesagt: Wenns nicht nicht in Ordnung nicht falsch ist, brauchen wir kein Pflaster drauf kleben.

Es sollte auch vermieden werden, eine Verneinung mit in den Variablennamen einzubauen. Dies kann bei späteren Vergleichen und Abfragen (siehe oben) zu einem Knoten im Gehirn führen. Deshalb sollte schonmal die Variable einfach OK heissen, besser noch bOK, damit man erkennt das es sich um einen Wahrheitswert handelt. Möchte man es noch weiter verbessern, wäre ein “sinvoller” Variablenname besser geeignet. OK kann alles bedeuten. Es sollte möglich sein, die Operation oder den Zustand zu assoziieren, für welche(n) dieser Wahrheitswert steht. Zum Beispiel bFileSaved für eine erfolgte Dateispeicherung. Somit wäre die obige Anweisung einfach durch

if( bFileSaved ) …

zu ersetzen. Nun kann man  mit einem Blick die ganze Situation erfassen. Oder meint Ihr nicht, das ich nicht nicht Recht habe, wenn ich die antinegierte Aussage, welche ich oben nicht nicht getroffen habe,  als nicht Richtig unter der Berücksichtigung einer unnegativen Nichtverneinung deute? 

Ich wühle mich momentan wieder durch einen riesigen Haufen Code! Und da habe ich dieses Schmankerl aufgetan:´

BOOL config_fits = Check();
if( config_fits )
{
    ...
}
else if( !config_fits )
{
    ...
}

Solangsam glaube ich, das Programmierer die größten Probleme mit Wahrheitswerten haben. Aber mal unter uns: Wie wichtig können die schon bei der Softwareentwicklung sein?

Es gibt Tage, da hinterfrage ich meine Sicht der Dinge. Denn manchmal habe ich das Gefühl, dass ich der einzige bin, bei dem es in den Gehirnwindungen knarzt, wenn er sowas sieht:

switch( CanLink(val,id,type) )
{
  case TRUE  : Message("CanLink() == TRUE" ); break;
  case FALSE : Message("CanLink() == FALSE"); break;
  default    : RvalOut( rVal, "AUTCanLink" ); break;
}

Natürlich weiss ich das TRUE unter Windows definitionsgemäß gleich 1 und FALSE gleich 0 ist. Was sogar in diesem Fall bedeuten könnte, das er tatsächlich manchmal in den default Block verzweigt. Doch erstens frage ich mich, ob eine Methode die “CanLink” heißst nicht wirklich nur true oder false zurückgeben sollte und zweitens wo die Logik bleibt, wenn wir bei bei einem binären Wahrheitswert eine dritte Möglichkeit abfragen.

Für ein solches Konstrukt gibt es in unserer Welt keine Entsprechung. Wenn wir eine Münze werfen und vorher auf Kopf oder Zahl setzen, diese Münze dann mit der Hand fangen und auf den Handrücken knallen, kommt kein Mensch auf die Idee vorher auszumachen, was passiert, wenn die Münze auf dem Rand landet.
Ein weiteres Beispiel wäre, dass ich jedesmal bevor ich jemanden frage: “Möchtest Du einen Kaffee?” erstmal Tee koche.

Was mir nicht klar ist, das Programme oft so undurchsichtig und krumm sind. Sie liefern oft eine Lösung von hinten durch die Brust ins Auge. Niemand würde nach “Feierabend” so verschroben denken. Warum aber während der Programmierung?

Da fällt mir einer dieser Programmierwitze ein, den eigentlich jeder Programmierer kennt und darüber lacht oder wenigstens schmunzelt. Er geht so:

bool Hoelle     = true;
bool Zugefroren = false;

if( Hoelle == Zugefroren )
{
    printf("Diese Applikation laeuft stabil!");
}

Für die Unkundigen: Hoelle und Zugefroren sind Wahrheitswerte und können nur wahr (true) oder falsch (false) sein. Dieses kleine Programm sagt nur aus, das die Software erst stabil läuft, wenn die Hölle zugefroren ist. Durch die Vorbelegung ist aber Hoelle==Zugefroren immer falsch und demnach wird diese Software niemals stabil laufen. Auch ich habe im ersten Moment geschmunzelt, weil es der täglichen Erfahrung ziemlich nahe kommt. Doch auch wenn die Aussage wahr ist, der Weg ist unschön. Der Wahrheitswert von Zugefroren ist völlig korrekt. Es beschreibt einen Zustand. Entweder ist etwas zugefroren oder nicht. Aber was will mir Hoelle=true sagen? Die Hölle ist kein Zustand der wahr oder falsch sein kann. Was würde mir Auto=false oder Wasser=true andeuten wollen? Auch hier sieht man wieder, der Teufel steckt nicht in der Hölle, sondern immer im Detail.