views:

244

answers:

4

What syntax do you think is better/more readable?

if(!myViewController.view.superview)

or:

if(myViewController.view.superview == nil)

Thanks!!

+7  A: 

I use the second form because the intention is more clear that way.

Mike Akers
Thanks.
Mk12
A: 

Here is a link to Google's Objective C coding standards: http://google-styleguide.googlecode.com/svn/trunk/objcguide.xml

They don't explicitly say which way they prefer but they do say to only use nil for logic checks, of which your example above would qualify.

chollida
+7  A: 

The two are very close, it comes down to personal taste or the conding standards of the project in question.

Saying !myViewController.view.superview meaning "no superview" is very clear.

Saying myViewController.view.superview == nil meaning superview is nil is also very clear.

I'd probably favor the former since if I was writing in English, I'd say:

if there is no superview then

I wouldn't say

if the superview is nothing then

But they are so close, and entirely equivalent, that it is hardly worth even being consistent with. Don't get me wrong, I'm all for consistency in general, it is just there really is no difference in readability between the two.

Peter N Lewis
A: 

Personally for a long time I used the latter expression, but reversed. Using "foo == nil" (or nil == foo, to avoid bugs caused by forgetting one '=') is more pedantic. Eventually you will get tired of typing it, and the first version is also immune to the accidental nil assignment bug.

It's good for new coders to be verbose in what they're coding, as it provides practise at forcing them to think about what's really going on, but later, of course switch to a version that is faster if it is equivalent.

If for some insane reason, nil pointers were not 0 anymore, but some other invalid value (there's entire gigantic regions of memory which are invalid as pointers), then using '!' wouldn't work anymore, but that will never happen (or if it did, they'd add support to the compiler to overload '!' so that it meant "not invalid" when used with an object pointer and would do the right thing anyway, or else the Objective-C developers of the world would go crazy).

The only subtle problem with this is that it can start to train you to confuse the value of C's boolean expressions with the values of other types, which they aren't the same thing. So, if you start to think a boolean expression is just a BOOL, say, you might assume that assigning any non-zero value to a BOOL variable will do what you want, but it won't. Since a BOOL is just a char (currently), if you do something like:

    - (BOOL)checkFoo {
  BOOL foo = [bar count]; // imagine count is > 255
    if(foo)
      [self doSomething];
    return foo;
}

where implicitly casting 256 or higher to BOOL gets you zero (NO) by truncation, not YES, which is what you want, versus

    - (BOOL)checkFoo {
  BOOL foo = ([bar count] > 0);
    if(foo)
      [self doSomething];
    return foo;
}

or

- (BOOL)checkFoo {
    if([bar count]) {
      [self doSomething];
      return YES;
    }
    return NO;
}

All I'm saying is, make sure you understand the background and the subtleties.

BoredAstronaut