On 10/05/2011, at 11:19 AM, Martin Batholdy wrote:
> BOOL st = [prefs boolForKey:@"optionA"];
> if(st == YES) { [buttonA setState:NSOnState]; }
> else if(st == NO) { [buttonA setState:NSOffState]; }
Apart from the advice already received, you can reduce this code to:
[buttonA setState:[prefs boolForKey:@"foo"]? NSOnState : NSOffState];
or even
[buttonA setState:[prefs boolForKey:@"foo"]];
if you are prepared to accept that NSOnState and NSOffState are 1 and 0
respectively (which they are, in fact, and unlikely ever to change, but if
you're paranoid, the first line fixes that).
Why bother? Because it's more readable than all those if/else constructions,
and hence, less prone to bugs. Also, if( st == YES)...else if(st == NO) is
redundant - a BOOL can only be YES or NO. The optimiser might optimise away the
second comparison anyway, but why be windy in the first place?
--Graham
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
