Ho letto questo post (Avoiding
Booleans) e l'ho trovato veramente illuminante:
Brad Abrams recently
posted another great excerpt from the
unfortunately named .NET Framework Standard Library Annotated Reference
Volume 2 :
Avoid creating methods with Boolean parameters. Boolean parameters make calls harder to
read and harder to write.
Indeed. What is the difference between..
Authorization("foo", true)
Authorization("foo", false)
Who knows? I've certainly made this mistake before. The
SLAR recommends ditching the boolean in favor of an enumeration:
Authorization("foo", AuthorizationCompletion.Pending)
Authorization("foo", AuthorizationCompletion.Finished)
Voilá. Self-documenting code. If you're not
careful, boolean parameters become
magic numbers .
Che dire... è proprio vero!
Proprio in questi giorni stavo tenendo un corso di C#... e durante la
spiegazione capitava spesso di vedere slide contenenti API che terminavano con
",true)" o ",false)" 
Prima che gli studenti me lo chiedessero esordivo con un bel...
"per favore qualcuno può guardare su MSDN cosa cavolo vuol dire quel
",true" visto che a memoria neanche chi ha progettato le API se
lo può ricordare..."
Certo... qualcuno può aver pensato "guarda questo teacher, non sa
neanche le API", poi ho fatto l'esempio dell'esame di certificazione su
VC++ 6.0 distributed, dove chiedevano di sapere a memoria le API, e tutti mi
hanno detto... ma come... c'è l'MSDN per le API...
Però non sempre c'è MSDN... e usare un bell'enum al posto di un
boolean rende SEMPRE molto più chiaro quello di cui si sta parlando 
.
Mi piace molto poi come prosegue il post:
Avoiding boolean parameters isn't a new idea, of course; similar advice
is dispensed by
C++ guru Herb Sutter in this 2002 C++ User's Journal article . What you may not realize, however, is that it's also a good idea to avoid booleans in your user interface. Jef Raskin explains in his book,
The Humane Interface :
Check boxes can leave the user guessing
what the alternative is. For example, if a check box labeled "Save to
archive on closing" is checked, the data will be saved to an archive when
the window is closed, but the label gives little clue as to what will happen
if the box is not checked. Will the data be saved somewhere else, not saved
at all, or will another option appear when you close the window? Often, the
best solution is to use a set of radio buttons; they are not modal, and the
user can clearly see not only the current state but also the alternative(s).
Whether checkboxes or radio buttons are used, it is important to label with
adjectives which describe the state of the affected object. If verbs are
used as labels, the user does not know whether the action has taken place or
is yet to take place.
For one-of-many choices, radio buttons are already the standard, and there is rarely any reason to use other mechanisms. Whenever possible, use radio buttons instead of checkboxes. Checkboxes work reliably only when the value of
the state controlled by the check is immediately visible or in short-term
memory.
As a developer my go-to boolean UI element is the
checkbox. If it can be true or false, it's a checkbox, right? Like so:
But what does the verb "Lock" mean? This checkbox
violates the Don't Make Me Think rule. Now watch what
happens when we change to adjectives and radio buttons:
This is conceptually identical to the code sample;
we simply switched from a boolean to an enumeration. It's amazing how obvious
the benefits are in retrospect, but it sure wasn't obvious to me. Until today.
Come non essere d'accordo!