Re: assignment in if clause
Re: assignment in if clause
- Subject: Re: assignment in if clause
- From: Michael Gardner <email@hidden>
- Date: Mon, 26 May 2008 14:12:14 -0500
- Domainkey-status: no signature
I disagree with the whole notion that using the result of an assignment
is "bad style" or "confusing". I find it quite clear and natural to use
constructs like "while (foo = [enumerator nextObject])", and I suggest
to those who are uncomfortable with the similarity of the = and ==
operators to use an editor that makes the difference clear, perhaps via
syntax coloring. And adding extra parentheses just to assure the
compiler that you know what you're doing is man serving machine, not the
other way around as it should be.
-Michael
Jonathan Prescott wrote:
> It's really the same issue as the "if" statement. To be pedantic, the
> "while" statement should read:
>
> while( (instance=[someEnumerator nextObject]) != nil )
>
> Jonathan
>
> On May 26, 2008, at 2:06 PM, Stuart Malin wrote:
>
>>
>> On May 26, 2008, at 7:13 AM, Jens Alfke wrote:
>>
>>>
>>>> I tend to write:
>>>>
>>>> if (self = [super init]) {
>>>> // do stuff
>>>> }
>>>> return self;
>>>
>>> Putting assignments in 'if' statements is bad style, because it's
>>> very easy to get them mixed up with the more common equality tests.
>>> In fact, putting '=' instead of '==' in an 'if' is a common enough
>>> error that GCC has compiler warnings for it, so code like the above
>>> will actually generate warnings if someone turns on those flags. For
>>> that reason, I would avoid using that syntax. A workaround for that is
>>> if ( (self = [super init]) != NULL )
>>> but I avoid that too. I just find that putting assignments into
>>> conditionals at all makes the code confusing; but YMMV.
>>
>> Since I hadn't received any warnings about embedded assignments in if
>> statement conditions, I realized I must not have all warnings turned
>> on... and so added -Wall to my project settings compiler flags. Well,
>> that humbled me because my next compile had more than 30 warnings.
>> These were easily and swiftly cleaned up, but my doing so leads to
>> another idiom/convention question:
>>
>> With -Wall enabled, the compiler complained about
>>
>> while (instance = [someEnumerator nextObject]) {
>>
>> so I changed that (in quite a few places) to:
>>
>> while ((instance = [someEnumerator nextObject])) {
>>
>> (the compiler is satisfied with this).
>>
>> Even though the double parens make clear that I had intended an
>> assignment, it looks odd, and I can't recall ever seeing anything like
>> this -- even in numerous example code snippets in the docs that use
>> enumerators. So, my question is, is this double paren idiom good, or
>> should I code such while loops in yet some other way?
>>
>>
>>
>> _______________________________________________
>>
>> Cocoa-dev mailing list (email@hidden)
>>
>> Please do not post admin requests or moderator comments to the list.
>> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>>
>> Help/Unsubscribe/Update your Subscription:
>>
>>
>> This email sent to email@hidden
>
> _______________________________________________
>
> Cocoa-dev mailing list (email@hidden)
>
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden