[webkit-dev] Bools are strictly worse than enums

Chris Marrin cmarrin at apple.com
Mon Dec 6 11:54:44 PST 2010


On Dec 6, 2010, at 10:15 AM, Darin Adler wrote:

> On Dec 4, 2010, at 3:01 PM, Maciej Stachowiak wrote:
> 
>> Passing a true or false literal (at least in cases where it's not the sole argument) is a likely indicator of unclear style, as opposed to taking a boolean argument.
> 
> Agreed.
> 
>> In fact, even putting a boolean literal in a named variable and then passing that is likely to be fairly clear.
> 
> Use of a boolean literal can easily hide the fact that a call site is passing a boolean to the wrong argument or even has the sense of the boolean backward. The enum technique is considerably more powerful in the way that it ties the call site to the called function, providing a benefit that goes beyond readability.
> 
> That having been said the enum has at least these costs:
> 
> - The enumeration definition has to be in a file included anywhere it’s used.
> - Coming up with good names for the enumeration and its values can be difficult.
> - At call sites that need to compute a value to pass in rather than passing a constant the enum can obscure the code’s meaning rather than clarifying it.
> - Mangled names of functions get longer.

I find one other cost when converting to enums. Since C++ doesn't do typing of enums, you have to worry about name clashes. This leads to enum names decorated with the enum type. Putting the enum in the associated class helps. But as the use of enums goes up you even have to worry about clashes within the class. Plus putting enums in a class requires qualifying each enum with the class name. All these things lead to reduced readability. I haven't found any guidance in the style guidelines about naming and qualifying enums. Right now you see every manner of enum naming imaginable. Adding something to the style guidelines would be very helpful.

I agree that using enums is better. But I'd like to get some guidance on how to do it "right".

-----
~Chris
cmarrin at apple.com






More information about the webkit-dev mailing list