Be explicit in your code

hsoi blog, talk 0 Comments

One of the coolest additions to the Objective-C language was properties.

One attribute of a property declaration is if the property is ‘atomic’ or ‘nonatomic’. However, for the longest time while you could explicitly set a property to ‘nonatomic’ you couldn’t explicitly set it to ‘atomic’. In some respects it didn’t matter because they were ‘atomic’ by default and most iOS programming uses ‘nonatomic’ properties. But I think it matters because your code — as documentation — cannot be explicit and thus fully convey the intentions of the programmer. That is, did they intend to make it atomic? or did they just omit or forget to specify? This is especially glaring in iOS code since ‘nonatomic’ is by far most common, so anything that implies otherwise looks odd… and was it intentional or not? [1]

Thus, I tend to err on the side of explicitness is good, since it makes the programmer’s intentions clear and avoids chance of mistake. It’s less likely that defaults will change, because there can be huge cost associated with doing so; but it does avoid that rare case too, if it might be relevant for your system.

But are there times when explicitness is not good, not warranted, or perhaps just a waste?

I would say when there isn’t necessarily an option, because “that’s just how it is”.

For example, the defined behavior of Cocoa objects (note, not an Objective-C thing; this is a Cocoa thing), is when they are allocated their instance variables are set to 0 or equivalent (nil, NULL, 0.0). Thus for you to have an -init method like:

- (id)init {
  self = [super init];
  if (self != nil) {
    _someVar = 0;
    _someObj = nil;
    _someFloat = 0.0;
  }
  return self;
}

is unnecessary. Your instance variables will be zero-ed out by definition of the environment we’re working within. This is a common behavior carry-over from people coming to Cocoa from other languages, like C++. Ultimately there’s no harm in doing this (just a little extra codegen), but really, it is best to know the environment you’re working within and work within it. Explicitness really isn’t an issue here because you are doing what the runtime provides. The only time you might need to be explicit is if you were doing something different, like _someFloat needed to be initialized to π.

The same could be said for the properties. What if the attributes of your property was to get the default attributes, no matter what they were? The intent was defaults, even if the OS changed the defaults? I would still say be explicit about this, through a comment to the side of the property declaration that is explicit to your intent.

We must remember that code is written once but maintained forever. It may be you that has to maintain it, or it may be someone else. But either way, chances are good the next time this code is looked at the person looking probably won’t know or understand why the code was as it was (even if it’s you maintaining your own code). Don’t leave the maintainer to guess as to your intentions: be explicit, be clear. It makes it far easier to work with the code in the long run.

 


[1] Thankfully this did eventually change, and via RADAR 12733222 I was able to gain clarification. As of Xcode 4.5.2 I noticed Xcode was consuming ‘atomic’ just fine, both in terms of syntax coloring and the compiler not choking on the keyword. Furthermore, the CLANG_WARN_OBJC_IMPLICIT_ATOMIC_PROPERTIES warning gave implication that there was support for both the ‘atomic’ keyword and support for being explicit about things. Nevertheless, documentation still lead one to believe there was no way to be ‘atomic’ without omitting the keyword. So my bug report did seem to spur an updating of the documentation. As well, I was told that explicit support for the ‘atomic’ keyword came in Xcode 4.2.  So now hopefully 3rd party code authors will update their code accordingly.

Leave a Reply