Are booleans as method arguments unacceptable? [cl

Question

A colleague of mine states that booleans as method arguments are not acceptable. They shall be replaced by enumerations. At first I did not see any benefit, but he gave me an example.

What's easier to understand?

file.writeData( data, true );

Or

enum WriteMode {
  Append,
  Overwrite
};

file.writeData( data, Append );

Now I got it! ;-)
This is definitely an example where an enumeration as second parameter makes the code much more readable.

So, what's your opinion on this topic?

Answer 1

The use of enums instead of booleans in your example does help make the method call more readable. However, this is a substitute for my favorite wish item in C#, named arguments in method calls. This syntax:

var v = CallMethod(pData = data, pFileMode = WriteMode, pIsDirty = true);

would be perfectly readable, and you could then do what a programmer should do, which is choose the most appropriate type for each parameter in the method without regard to how it looks in the IDE.

C# 3.0 allows named arguments in constructors. I don't know why they can't do this with methods as well.

Answer 2

There are two reasons I've run into this being a bad thing:

1. Because some people will write methods like:

   ProcessBatch(true, false, false, true, false, false, true);
   

   This is obviously bad because it's too easy to mix up parameters, and you have no idea by looking at it what you're specifying. Just one bool isn't too bad though.

2. Because controlling program flow by a simple yes/no branch might mean you have two entirely different functions that are wrapped up into one in an awkard way. For instance:

   public void Write(bool toOptical);
   

   Really, this should be two methods

   public void WriteOptical();
   public void WriteMagnetic();
   

   because the code in these might be entirely different; they might have to do all sorts of different error handling and validation, or maybe even have to format the outgoing data differently. You can't tell that just by using Write() or even Write(Enum.Optical) (though of course you could have either of those methods just call internal methods WriteOptical/Mag if you want).

I guess it just depends. I wouldn't make too big of a deal about it except for #1.

Answer 3

Booleans may be OK in languages that have named parameters, like Python and Objective-C, since the name can explain what the parameter does:

file.writeData(data, overwrite=true)

or:

[file writeData:data overwrite:YES]

Answer 4

It does make things a bit more explicit, but does start to massively extend the complexity of your interfaces - in a sheer boolean choice such as appending/overwriting it seems like overkill. If you need to add a further option (which I can't think of in this case), you can always perform a refactor (depending on the language)

Answer 5

It really depends on the exact nature of the argument. If it is not a yes/no or true/false then a enum makes it more readable. But with an enum you need to check the argument or have acceptable default behaviour since undefined values of the underlying type can be passed.

Answer 6

This is a late entry on an old post, and it's so far down the page that nobody will ever read it, but since nobody has said it already....

An inline comment goes a long way to solving the unexpected bool problem. The original example is particularly heinous: imagine trying to name the variable in the function declearation! It'd be something like

void writeData( DataObject data, bool use_append_mode );

But, for the sake of example, let's say that's the declaration. Then, for an otherwise unexplained boolean argument, I put the variable name in an inline comment. Compare

file.writeData( data, true );

with

file.writeData( data, true /* use_append_mode */);