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

[David Ayers]

Richard Frith-Macdonald wrote:
> On 31 Jan 2004, at 09:08, David Ayers wrote:
>
> > 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.
>
> I think the documentation strongly implies that the people writing it 
> also consider the case of some methods returning non YES/NO values in a 
> BOOL to be a bug/misfeature, as they warn about those cases where it 
> happens.  We obviously have to code specially to deal with those cases.

Are you refering to the "converting it if necessary."?  Otherwise I 
don't see where it implies that.

> >  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().)
>
>
> I like isYES() best of the macro names.
>
> However, while the definition above *might* be appropriate for 
> production code, I think it is wrong for a development
> system, and certainly if NDEBUG is not defined I think it should be of 
> the form -
>
> #define isYES(_exp) ((_exp) == YES) ? 1 : (((_exp) == 0) ? NO :  
> ([NSException raise...],0)

Well, actually this will probably have to be done in a (static inline) 
function to avoid evaluating the expression mutliple times and to allow 
constructs like:

for (...;isYES([fm removeFileAtPath: path handler: handler]);...) {...}

> Making a coding standard about this was not my idea ... I prefer to let 
> people make their
> own choices generally, but as a matter of preference I would suggest 
> that for clarity, any
> such standard should suggest that we use a simple boolean expression in 
> any conditional
> with the only exception being for cases where the expression is clearly 
> a method/function
> returning a boolean.  So I'm fine with your example above (though I 
> would consider
> it good style to check the results of the method explicityl, just not 
> mandatory).

Yes, and I'd also rather view it a guideline.  A guidline with the 
purpose of writing robust code (or the alternative approach, asserting 
robustly written code if you wish).

> I agree ... wonderful naming and explicit testing are both good.  
> However, naming alone
> is rarely reliable because names that are clear to one person are 
> sometimes confusing
> to another, especially with people for whom english is not their native 
> language. For that
> reason I tend to prefer explicit testing even where I think variable 
> names are clear.
>
> > - ???
> >
> > 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.
>
>
> Yes, I think where we have a function/method whose name plainly implies 
> that it
> is a boolean predicate it seems very clumsy to test explicitly again ... 
> in these cases
> a test is really more to guard against implementation problems than to 
> provide
> clarity.

Well, I believe that we may have very different interpretation of when a 
method/variable name is ambiguous and when and where we would assert 
that the implementation is correct, I'm a bit reluctant to do any 
cleanup in core.  But for sake of productivity, if we come up with a 
guideline to make these decisions, I'll can apply them.


> > 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.
>
>
> I'm happy to use IsYES() rather than == YES if it raises an exception 
> (or logs a warning),
> but I consider != NO to be both poor style and less likely to expose 
> coding errors, and
> therefore to be avoided.

I guess we'll have to agree to disagree on this, as I find != NO the 
only solution to write robust production code, that == YES is error 
prone and raising an exception is wrong as I don't see a strong mandate 
of not being able to rely on standard C truth semantics.  But I also 
don't think the matter is serious enough to spend much more time on it, 
so as long as we use =! NO as default (debug=no) and that we always 
check #ifndef isYES before doing anything, I'll conceed.

Cheers,
David