Re: [RFA]: BOOL coding standards (Was: Problem with +numberWithBool: ?)

[David Ayers]

Nicola Pero wrote:
> The problem with coding conventions is that people often don't follow
> them.

Yet others attempt too :-) especially when trying to fix correctness issues.


> I think readable code says "if (condition)" where condition is a condition
> clearly expressed, almost in English.
>
> If condition is a method call returning a boolean, or a boolean variable,
> I'm happy with using "if (condition)".  In all other cases when a variable
> is checked, I prefer to see written down what it is checked against.

[snip]

> About booleans, that's the part where I'm personally more uncertain :-)
>
> It seems a reasonable convention to use 'if (condition)' and 'if (!  
> condition)'.  That's logical, and it's supposed to be readable.
>
> So I vote for that.

I think I'm with you here.

[snip]

> The other thing is that often methods are badly named, or just return
> booleans for operations with some convention you have to know, so you can
> easily end up having
>
> if (! [self processData: data])
>
> and when I read that I can feel that it requires me a fraction of a second
> of additional thinking, as you then have to actually think why/what
> happens when -processData: returns YES, and why/what happens when it
> returns NO, and which of the two cases is covered by the condition.
>
> In such cases, I often get the feeling that
>
> if ([self processData: data] == NO)
>
> can be a lot more readable, because the boolean returned by the method is
> not really a "condition", but it's more like a return value, and this
> immediately tells you that if the return value is NO, the branch is
> executed.  It's like explicitly writing down in a braindead simple way
> when the branch is executed - of course it adds nothing, but it saves a
> few cpu cycles in my head when I reread the code.
>
> Maybe in those cases the method should have a different name ?

When it comes to core we often don't have a choice :-).  But in these 
cases I think it's fair enough to use comparisons.

But I agree that this is a correctness issue.  I.e. is it valid to 
assert that BOOL may only have the values YES and NO i.e. are the two 
defines (YES/NO) the only valid values for the type BOOL and do we have 
a "license" to enforce that by:

a) potentially raising upon different values
b) using "== YES" as a valid comparison.

I'm not convinced we do and maybe this is a question for 
address@hidden

OTOH, I think the simple solution is to avoid the discussion an simply 
not use '== YES' either in favor of not adding the extra test or by 
testing with "!= NO" (even if that is not as trivial to parse).

Cheers,
David