[webkit-dev] Bools are strictly worse than enums

Eric Seidel eric at webkit.org
Fri Dec 3 13:54:28 PST 2010


I'm not sure we have any examples of bool passing like that in real code.

The case I'm concerned about is not one of single argument bools:

doSoemthing(bool)

but more of multi-argument functions:
doSomething(something, bool)

I'm trying to write a rule which can be easily automated by
check-webkit-style.

It's possible we could tighten the rule further to only allow
single-argument bools where "set" is in the function name.

It sounds like most folks are in agreement.  We should add a rule like this
to check-webkit-style.  Sounds like Dave Levin may already have something
partial in the works.

-eric

On Fri, Dec 3, 2010 at 1:45 PM, Ryosuke Niwa <rniwa at webkit.org> wrote:

> On Fri, Dec 3, 2010 at 1:37 PM, David Hyatt <hyatt at apple.com> wrote:
>
>> The only exception I would make to this rule is if all the call sites use
>> variables and never pass in raw true or false.  In that case there's no loss
>> of readability, and whether you use an enum vs. a bool is irrelevant.
>>
>> I think in general the rule should be "Keep your call sites readable, and
>> convert to enums if you find that the call sites are becoming inscrutable."
>>
>
> That rule makes sense to me.
>
> On Fri, Dec 3, 2010 at 1:40 PM, Eric Seidel <eric at webkit.org> wrote:
>
> Dave, I'm not sure I understand your exception.  Could you give an example?
>
>
> I think what he means is that
> bool doSomething();
> void doSomethingElse(bool);
>
> and the only case we always call doSomethingElse with a return value of
> some function or with a variable:
> doSomethingElse(doSomething());
> doSomethingElse(shouldNotDoSomethingElse);
> etc...
>
> and we never call it with raw true/false:
> doSomethingElse(true)
> doSomethingElse(false)
>
> - Ryosuke
>
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20101203/796e4978/attachment.html>


More information about the webkit-dev mailing list