gnustep-dev
[Top][All Lists]
Advanced

[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: Fri, 30 Jan 2004 17:45:50 +0000


On 30 Jan 2004, at 17:07, Richard Frith-Macdonald wrote:


On 30 Jan 2004, at 16:00, Alexander Malmberg wrote:

Manuel Guesdon wrote:
My rule: be strict for output and flexible for input :-)

A very good rule. :)

http://www.faqs.org/docs/jargon/P/Postel's-Prescription.html

So what do we do ?

I've attached a patch to our coding standards. OK to commit? If so, new
code will work ok, and I'll get to work on patching core/ (hopefully
with some help from David Ayers :).

Predictably perhaps,  I don't really like it ...

I think the idea a boolean type is an improvement over C, and it worries
me that being too tolerant will encourage bad coding (and may make
the code less readable).

If we want to mandate a standard way of testing the results of an operation
which is supposed to return a BOOL, perhaps use of a macro might be
better.
eg.

if (IsYes([receiver aMessage])) ...

Where the macro could log a warning or raise an exception (or do nothing)
for a non YES/NO value depending on a developers preferences.

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.

Anyway ... the macro scheme is intended as something that can please
everyone - having a warning/exception is certainly better than just
hoping that the NO branch of an if/else will expose errors in the
code returning the BOOL, and having the macro do nothing but treat
the non YES/NO values as a YES should please anyone who wants
a BOOL to be the same thing as a char/int





reply via email to

[Prev in Thread] Current Thread [Next in Thread]