Re: Avoiding == and = mixup in if statements
Re: Avoiding == and = mixup in if statements
- Subject: Re: Avoiding == and = mixup in if statements
- From: Chris <email@hidden>
- Date: Fri, 21 May 2004 14:39:49 -0400
On Friday, May 21, 2004, at 02:28PM, Ondra Cada <email@hidden> wrote:
>
Steve,
>
>
On 21.5.2004, at 19:32, Steve Bird wrote:
>
>
> Can you explain how I can remember to put the arguments in backwards,
>
> if I can't remember to use "==" instead of "="?
>
>
;)
>
>
Actually, in my *personal* opinion the best pattern for pointers (which
>
includes, of course, objects) is omitting the "nil" altogether: a
>
condition
>
>
if (myObj) whatever...
>
>
reads very intuitively "if there's myObj do whatever" (or, "if
>
(!myObj)..." reads "if there's no myObj..."). And, of course, no typo
>
is possible.
>
>
That of course does not solve cases with a more complicated
>
expressions, like
>
>
if (myObj==[NSNull null]) ...
>
>
for these I personally would recommend the (already mentioned by
>
others) -Wparentheses warning.
While I do use the if(myObj) syntax sometimes, I usually think of it as less intuitive than the explicit comparison. Simply a matter of preference, of course, but I figured I might as well comment ;)
To stray back "on topic", how touchy is -Wparentheses? Would while(myObj = [iterator nextObj]) cause it to warn? I imagine pre-processor directives exist to enable/disable the warning around known ok blocks? Where possible I like to make sure that no warnings are being generated.
Chris
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.