[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RFA]: BOOL coding standards (Was: Problem with +numberWithBool: ?)
From: |
Richard Frith-Macdonald |
Subject: |
Re: [RFA]: BOOL coding standards (Was: Problem with +numberWithBool: ?) |
Date: |
Sat, 31 Jan 2004 19:26:04 +0000 |
On 31 Jan 2004, at 09:08, David Ayers wrote:
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.
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.
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)
If you know that a method is documented as returning bad values in a
BOOL, you can handle
those values specially, but the default way of handling BOOL return
values should be to expose
incorrect code in the method being called, not to hide it. Raising an
exception on receiving a
non-YES/NO value is even better for this than simply testing for '_exp
== YES' is. As long as we
don't have proper boolean support in the compiler (a true boolean with
warnings generated if
an attempt is made to assign a non-YES/NO value to a boolean without an
explicit cast), we
may as well use the this feature to help catch errors
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]))
{
...
}
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).
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.),
And misbehaving categories.
- 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).
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.
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.
- Re: Problem with +numberWithBool: ?, (continued)
- [RFA]: BOOL coding standards (Was: Problem with +numberWithBool: ?), Alexander Malmberg, 2004/01/30
- Re: [RFA]: BOOL coding standards (Was: Problem with +numberWithBool: ?), David Ayers, 2004/01/30
- Re: [RFA]: BOOL coding standards (Was: Problem with +numberWithBool: ?), Nicola Pero, 2004/01/30
- Re[2]: [RFA]: BOOL coding standards (Was: Problem with +numberWithBool: ?), Manuel Guesdon, 2004/01/30
- Re[2]: [RFA]: BOOL coding standards (Was: Problem with +numberWithBool: ?), Nicola Pero, 2004/01/30
- Re[3]: [RFA]: BOOL coding standards (Was: Problem with +numberWithBool: ?), Manuel Guesdon, 2004/01/30
- Re: [RFA]: BOOL coding standards (Was: Problem with +numberWithBool: ?), David Ayers, 2004/01/31
- Re: [RFA]: BOOL coding standards (Was: Problem with +numberWithBool: ?),
Richard Frith-Macdonald <=
- Re: [RFA]: BOOL coding standards (Was: Problem with +numberWithBool: ?), David Ayers, 2004/01/31
- Re: [RFA]: BOOL coding standards (Was: Problem with +numberWithBool: ?), David Ayers, 2004/01/31
- Re: [RFA]: BOOL coding standards (Was: Problem with+numberWithBool: ?), Alexander Malmberg, 2004/01/31
- Re: [RFA]: BOOL coding standards (Was: Problem with +numberWithBool: ?), Kazunobu Kuriyama, 2004/01/30
- Re: [RFA]: BOOL coding standards (Was: Problem with +numberWithBool: ?), Richard Frith-Macdonald, 2004/01/30
- Re: [RFA]: BOOL coding standards (Was: Problem with +numberWithBool: ?), Richard Frith-Macdonald, 2004/01/30
- Re: [RFA]: BOOL coding standards (Was: Problem with +numberWithBool: ?), Adam Fedor, 2004/01/30
- Re: [RFA]: BOOL coding standards (Was: Problem with +numberWithBool: ?), Sheldon Gill, 2004/01/31
- Re[2]: [RFA]: BOOL coding standards (Was: Problem with +numberWithBool: ?), Manuel Guesdon, 2004/01/31
- Re: [RFA]: BOOL coding standards (Was: Problem with+numberWithBool: ?), Alexander Malmberg, 2004/01/31