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

[Adam Fedor]

On Friday, January 30, 2004, at 10:45 AM, Richard Frith-Macdonald wrote:

> I know it's bad form to follow up on my own post but ...
> Where I'm coming from is this ... I remember coming across more cases
> where an non YES/NO value returned in a BOOL was due to a coding
> error and a symptom of a bug than cases where code simply returned
> a non-zero char intending it to be treated as YES.
> Mostly when methods return a BOOL the YES response is the success
> while NO is a failure and triggers remedial action or logging etc in 
> the
> code ... so testing for equality to YES tends to make buggy code show
> up.  That, as well as readability, made me switch to testing for YES
> explicitly a few years ago.
>
> It's quite possible that your experience is the opposite, and you've 
> had
> more problems the other way round ... so I don't claim that testing
> against YES definitely produces more robust code, just that it seems
> to have done so for me.

Sure. I often write:

if ([myObject doSomething]) ...

which is immediately understandable at a glance. But when I have a 
misbehaving program, I often wonder, is it really doing what I think 
it's doing?

It's particularly true when interacting with traditional C functions, 
where 0 means no error and any non-zero value is an error.