|
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.htmlSo what do we do ?I've attached a patch to our coding standards. OK to commit? If so, newcode 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 worriesme 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 operationwhich 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
[Prev in Thread] | Current Thread | [Next in Thread] |