Design Guidelines Update: Enums vs Boolean Arguments

re: Design Guidelines Update: Enums vs Boolean Arguments

nfactorial — Mon, 12 Jan 2004 19:19:00 GMT

I can see why it can become heated, my guideline for boolean parameters are to only use them if the method is a statement. ie.

myObject.Enable( true );

(Or somesuch, just an example). A pet-hate of mine in the current API is the boolean inside System.String.Compare. When reading code the line:

System.String.Compare( stringA, stringB, true );

never suggests to me 'Oh, that's case insensitive' (well, it does, but only 'cause I've used the method a few times :).

However, I see the reasoning for the above guidelines and they seem pretty solid if adhered to :)

n!

Design Guidelines Update: Enums vs Boolean Arguments

jeremy's wayward thoughts — Mon, 12 Jan 2004 23:36:00 GMT

This from Brad Abrams;  This was a pretty heavily debated guideline internally, I think we reached a good conclusion... Your feedback welcome as always!  The full guidelines can be found here, we will be roll this (and other updates) into it for the whidbey release. Enums vs Boolean Arguments A framework designer is often faced with the choice of when to use enums and when to use Booleans for method and constructor arguments.  In general terms you should favor using enums where it makes the readability of source code more explicit and therefore easier to understand.  Anywhere using enums would add unneeded complexity and actually hurt readability of source code Booleans should be preferred.              Do use enums if you two or more arguments that are Booleans. Enums are much more readable (in books, documentation, code reviews, etc).  Consider a method call that looks such as: FileStream f  = File.Open (“foo.txt”, true, false); This call gives you no context whatsoever to understand the meaning behind true and false.  Now consider if the call where: FileStream f  = File.Open (“foo.txt”, CasingOptions.CaseSenstative, FileMode.Open); Annotation:  Some have asked why we don’t have a similar guideline for integers, doubles, etc, should we find a way to “name” them as well?  There is a big difference between numeric types and Booleans: you almost always use constants and variables to pass numerics around, because it is good programming practice and you don’t want to have “magic numbers”. However, if you take a look at any managed code-base, this is almost never true of Booleans. 80% of the time a Boolean argument is passed in as a constant, and its intention is to turn a piece of behavior on or off. We could alternatively try to establish a coding guideline that you should never pass a...

Design Guidelines Update: Enums vs Boolean Arguments

jeremy's wayward thoughts — Mon, 12 Jan 2004 23:44:00 GMT

On enums and Boleans Via Brad Abrams; A framework designer is often faced with the choice of when to use enums and when to use Booleans for method and constructor arguments. In general terms you should favor using enums where it makes the readability of source code more explicit and therefore easier to understand. Anywhere using enums would add unneeded complexity and actually hurt readability of source code Booleans should be preferred....

re: Design Guidelines Update: Enums vs Boolean Arguments

Mike Dimmick — Wed, 14 Jan 2004 18:19:00 GMT

I'd also suggest the guideline, 'Only use booleans when the two possible values are actually opposites.'

Inspired by your use of Bold and NotBold above...

re: Design Guidelines Update: Enums vs Boolean Arguments

nfactorial — Fri, 16 Jan 2004 14:39:00 GMT

That's ok if the operation is a statement, font.SetBold( true ) [ignore the fact this would be a property, just an example :)]. If it's within a more complex method call true\false doesn't inform the user what its doing...

font = CreateFont( "Times New Roman", true );

Does 'true' imply bold? underlined? strikeout?

Whereas you can exactly what's happening with the line:

font = CreateFont( "Time New Roman", FontStyle.Bold );

n!

Design Guideline Updates

Chris Burrows .NET Blog — Mon, 19 Jan 2004 13:00:00 GMT

re: Design Guidelines Update: Enums vs Boolean Arguments

eriksalt — Tue, 20 Jan 2004 15:38:00 GMT

If I understand the above correctly, then the main trade-off here is (1) Increased Readability vs. (2) The increased effort & complexity of having to declare new enum types all the time. I understand that there are some other side-cases relating to enum performance, but I think that this trade-off represents the main thrust of the guideline. I had thought that a major factor in deciding which way to go would 'have been how often is the a bool is passed to a family of methods/properties to represent the same concept?' In other words, if the bool is only used in one method, then it may not be worth it to create the enum. I think this concept (number of declarations) plays in with the other factors you mentioned above. I am sure you have thought about this already, and would be interested to hear those thoughts.

re: Design Guidelines Update: Enums vs Boolean Arguments

nfactorial — Wed, 21 Jan 2004 15:07:00 GMT

Yes, although "having to declare new enum types all the time" makes it sound like a frequent thing when it isn't really. :)

Apart from increased readability, an enumeration ensures the programmer is explicit about his\her desire. 'true\false' is quite ambiguous and may lead to versioning problems in the future (note, this is all IMHO :).

I'm not saying 'it will cause versioning problems', just that 'its possible'. And reducing 'possible' problems isn't such a bad idea (hopefully).

Of course, if the boolean is used in just one method call then an enumeration may just be increasing the amount of work.

For such things I would usually create two methods, with differing names. Something akin to 'strcmp' and 'strcmpi', from the C standard library for case sensitive and case insensitive comparisons. Except I'd try and choose more meaningful names :)

n!

Design guidelines from Microsoft

James Geurts' Blog — Thu, 29 Jan 2004 18:30:00 GMT

Microsoft Design Guidelines

James Geurts' Blog — Mon, 01 Mar 2004 20:34:00 GMT

Write Readable Code By Making Its Intentions Clear

you've been HAACKED — Fri, 20 Apr 2007 10:59:02 GMT

Write Readable Code By Making Its Intentions Clear

Community Blogs — Fri, 20 Apr 2007 13:22:12 GMT

I don’t think it’s too much of a stretch to say that the hardest part of coding is not writing code,