views:

76

answers:

4

Each time I'm writing a method that takes a boolean parameter representing an option, I find myself thinking: "should I replace this by an enum which would make reading the method calls much easier?".

Consider the following with an object that takes a parameter telling whether the implementation should use its thread-safe version or not (I'm not asking here if this way of doing this is good design or not, only the use of the boolean):

public void CreateSomeObject(bool makeThreadSafe);
CreateSomeObject(true);

When the call is next to the declaration the purpose of the parameter seems of course obvious. When it's in some third party library you barely know, it's harder to immediately see what the code does, compared to:

public enum CreationOptions { None, MakeThreadSafe }
public void CreateSomeObject(CreationOptions options);
CreateSomeObject(CreationOptions.MakeThreadSafe);

which describes the intent far better.

Things get worse when there's two boolean parameters representing options. See what happened to ObjectContext.SaveChanges(bool) between Framework 3.5 and 4.0. It has been obsoleted because a second option has been introduced and the whole thing has been converted to an enum.

While it seems obvious to use an enumeration when there's three elements or more, what's your opinion and experiences about using an enum instead a boolean in these specific cases?

A: 

You can make use of named parameters in C# 4.0:

CreateSomeObject(makeThreadSafe : true);
devoured elysium
A: 

Clearly the second approach is more readable without an IDE. If you are in VS, you can use intellisense to grok the parameters, although admittedly this can be a bit clumsy at times.

If you are in C# 4.0, you can use named parameters to make your intent clear.

Robert Harvey
+6  A: 

.NET 4.0 might help here. You can use named parameters:

CreateSomeObject(makeThreadSafe : true);

For older versions it can be useful to create temporary variables instead.

bool makeThreadSafe = true;
CreateSomeObject(makeThreadSafe);
Mark Byers
+1  A: 

I think it would depend on the semantics of your methods, for example does your boolean value actually represent a boolean ? Or is it used just to flag the presence, not presence of another thing?

For example:

// If true, uses 64 bit numbers, if false, 32.
doSomething(boolean)

Even if you know (that at least for the foreseeable future that won't change (unless you want to support 16 or even 8 bits) it would be far more easier to read if you used an enum:

Options.Use32Bit,
Options.Use64Bit.
Francisco Soto