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

[David Ayers]

OK folks,

it's pretty clear that some of us consider accepting on non-YES-NO 
values for BOOL as "non-conforming" of s strict interpretation of the 
"type" BOOL, yet we have clear indication in a reference documentation 
that we (and people developing on top of the API) should not rely on 
[someValue boolValue] == YES to work.  As this differs from the OpenStep 
spec, which merely states that boolValue should return the receiver's 
value as a boolean value, I can understand that some people would like a 
more rigorous enforcement.  But let's try to be as robust as possible by 
default.  Right now I think Richards macro (though it may still look a 
bit awkward) is the best way to replace '== YES' tests.  I propose to 
change the appearance a bit like:

#ifndef isYES
#define isYES (_exp) (_exp != NO)
#endif

and declare it in NSObject.h (for *-gnu-*) and GNUstep.h (for everyone 
else).  (I think that would be the correct place.)  (Actually to be 
consistent with the other macros it maybe should probably be IS_YES() 
but I'd really prefer isYES() to either that or IsYes()/isYes().)

Now /when/ it makes sense to use the the test is a separate issue.  I 
believe that we shouldn't require tests on return values of methods and 
functions that return BOOL in general.  We already omit the test often 
and I don't see any good reason to add them to expressions like:

  if (obj != nil && ([obj isKindOfClass: NSStringClass]
    || [obj isKindOfClass: NSNumberClass]))
    {
...
    }

I guess we could/should use isYES on testing(/assigning)
- values returned by boolValue (which is documented to possibly return 
something else than YES/NO to guard against /misbehaving/ custom 
subclasses.),
- incoming parameters
- and possibly to test BOOL variables for extra clarity (but that's 
debatable... because if clarity is needed then the better fix is to 
unambiguously name the variable but I'm not religious about it).
- ???

When there is a single method to test like:

-  if ([o isKindOfClass: NSStringClass] == YES)
+  if (isYES([o isKindOfClass: NSStringClass]))

the test just seems redundant to me, but maybe that's just personal 
preference.

I do think our coding guidelines should mention to use isYES() instead 
of '== YES', though.  Maybe they should also comment about when we want 
to use the test and when it's considered redundant.  Actually, there are 
other conventions that should be amended that have comparable or more 
relevance, but that shouldn't be a reason to not include this IMHO.

Cheers,
David