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

[Nicola Pero]

> > So what do we do ?
> 
> I've attached a patch to our coding standards. OK to commit?

It looks a bit too much like religious warfare to go in our coding
standards.  You need more tactful statements in there I think.  :-)

I think a BOOL variable should take the values 0 for NO and 1 for YES.

Coding standards should recommend that all code writing or returning a
BOOL always uses 0 for NO and 1 for YES, as everyone knows and agrees on
those values and their meanings.

Different values for BOOL variables should never occur in good written
code (they just cause confusion, as they did in fact otherwise we wouldn't
be having a thread on this :-).

If a different value occurs (presumably generated by third-party code) it
should be treated as YES (symmetry breaking, it's either YES or NO, and
since for old C any non-zero integer is a match for an if (), let's use
YES to produce a similar behaviour) - I suppose we all agreed on this, but
it still looks like the expectional condition to me, and should be
described as such in the spec.

I don't have particular objections to change 'if ([this canDoThat] ==
YES)' into 'if ([this canDoThat])', if we write clearly in the coding
standards that this can be done only for methods returning a BOOL, and
that everything else (pointers, integers, etc) must be compared against
something.  So whenever you'd see 'if ([this doThat])' you know that the
result type must have been a BOOL since it's compared to nothing.

At the end of the day, I agree with you in how to do things :-) but I'd
like coding standards to be written and presented in a tactful and
balanced way.  Otherwise they'll generate more flamewars than they
prevent. :-)