posts - 4238, comments - 3946, trackbacks - 370

My Links

News



Subscribe Subscribe

image image image





This is my personal weblog. These postings are provided 'AS IS' with no warranties, and confer no rights. The views expressed on this weblog are mine alone and do not necessarily reflect the views of my employer.

Licenza Creative Commons

Tag Cloud

Archives

Post Categories

Evitare i boolean??? E' proprio vero!

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:

A typical boolean checkbox

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:

Boolean checkbox converted to radiobutton enumeration

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!

Print | posted on sabato 29 ottobre 2005 15:53 |

Comments have been closed on this topic.

Powered by:
Powered By Subtext Powered By ASP.NET