I was reading a collegues code review the other day and they raised the point that they didn’t understand what the new parameter in a call meant. The reason for this was the new code simply stated something like:
MyMethod(Name, Address, true)
Naming conventions means the first two arguments do a good job of conveying what they are supplying to the method. The problem with the third argument is it’s more of a statement rather than a hint to its (ahem) true meaning. The proposed solution was to swap this out for a enum; UpdateProcess.New | UpdateProcess.Edit Ok I can see how that might work, but the obvious point that seemed to have been missed is why not simply use a variable? If I rewrote the call using a variable for the Boolean wouldn’t this sort out the problem?
MyMethod(Name, Address, isNew)
Well to some extent it does, at least now the reader has some clue to the intent, however, if true==isNew what does false mean? What is the opposite of isNew? Ok you’ve read that the intent is to be new or edit, but you’ve had to discover that by some other means, the code doesn’t not convey that. You’d have to read a comment or drill down into MyMethod to understand that. This is where the (ahem..again) argument for a enum gains the upper hand. I’ll re-write it again.
MyMethod(Name, Address, UpdateProces.New)
Once again we can see what the caller wants to do a "new", whatever that is. But now the reader (assuming a decent editor) can hover over UpdateProcess and see what the alternatives are, in a binary case such as this then there are only two, previously represented by true/false. But now the reader has a chance of understanding the authors intent.
So what this long-winded blog entry is trying to say is, "do we need Boolean flags now?" I don’t think there is much need for them now, so I’ll shed a little tear for a faithful old friend and usher in more of those ugly type-space-hogging enums. I guess this is progress. R.I.P bool flag.
IT Bytes 