Wann ein bool ein bool ist - und wann ein Enum besser ist


Thomas Wölfer
Thomas Wölfer

10. Oktober 2006


Das größte Problem für booleans in C# ist die Lokalisierung: Wenn man erwarter, das ein bool im PropertyGrid mit deutschem Language Pack als "wahr/falsch" oder "ja/nein" angezeigt wird - dann täuscht man sich. Auch da taucht einfach "true/false" auf. Für eine Softwareentwicklungsumgebung mag das ja ok sein, für einen normalen Windows-Client ist es das wohl eher nicht.

Man muss den Kram also selbst lokalisieren. Und dabei stellt sich die Frage - hätte man nicht von vornherein besser einen Enum statt einen boolean genommen? Die Antwort lautet oft: Ja, genau.

Zusammen mit einer etwas ungünstigen Namensgebnung geht das Problem mit bools schon bei Methodenaufrufen los. Mal angenommen, man hätte die folgende Signatur:

void CalculateLogicalIntermediate( Point a, Point b, bool designFlag)

- dann hat man auf jeden Fall schon mal einen blöden Namen für den dritten Parameter gewählt. Was bitte ist denn ein "designFlag"? Und vor allem - muss man es auf true setzen, wenn das "design" denn stattfinden soll, oder doch auf false. Schwer zu sagen...

Schon viel besser ist es doch so:

enum DesignFlag { UseDesignMethology, DontUseDesignMethology }
void CalculateLogicalIntermediate( Point a, Point b, DesignFlag designFlag)

Wie findet man nun heraus, ob man für einen Parameter einen boolean nimmt oder nicht?

Eigentlich ganz einfach: Ein bool ist dann ein bool, wenn eine einfache Verneinung zum richtigen (vollständigen) Ergebnis führt. Und keiner, wenn nicht. Zum Beispiel:

bool isThicknessConstant;

Wenn die Dicke nun nicht konstant ist - wie ist sie denn dann definiert? Linear? Qudaratisch? Wenn isThicknessConstant=false, dann muss man erst noch die "echte" Art und Weise ermitteln - eine einfache Verneinung reicht also nicht aus, um zum vollständigen Ergebnis zu kommen. Die richtige Art wäre also

Enum ThicknesDefintion { Constant, Linear, Cubic, Unknown }