Subjective-C: I use property (dot) syntax liberally
Modern Objective-C gives us tools—like autosynthesized property ivars, ARC, and optional protocol methods—that allow writing clearer code which better expresses our intentions.
One of these tools is dot syntax for calling property getters and setters. For a while, after 2006, Objective-C “purists” avoided using dot syntax, but it’s now—finally!–a widely-accepted practice.
Or at least it’s accepted for things defined as @properties. Many programmers cringe if you use dot syntax for calling a method that’s not declared as a property, like NSArray’s -count method.
Oh, wait. That is a property, now. But it wasn’t in iOS 7. Hm. What changed about it?
It’s still an idempotent method, with no [side effects](http://en.wikipedia.org/wiki/Side_effect_(computer_science), which takes no parameters and returns a value. And we can safely assume that—though it’s exposed as a method in iOS 7 and a property in iOS 8—its implementation didn’t change significantly between the two OS versions.
There is no difference
This is just a different syntax for exposing the same method. This is why I have long argued—and in codebases that accept it, practiced—that methods which look, walk, and talk like getter methods should be called with dot syntax.
What exactly do I mean by “like getter methods”? Any method which meets these criteria can and should be called with dot syntax:
- It is idempotent. (The method returns the same value if you call it twice on the same object, barring mutations, and it has no side effects—by which I mean, it modifies no state visible to, and has no observable interactions with, the outside world).
- It takes no parameters.
- It returns a value.
But: while there is no technical difference between dot syntax and square bracket syntax for calling these methods, that’s not in and of itself a solid argument in favor of dot syntax. I use dot syntax because it provides…
A clearer expression of intent
If I’m using a a method meeting the criteria laid out above, calling it with dot syntax provides better expression of my intent.
That is, square brackets for a message send feel “action-y”; they say “object, do this thing”. But dot syntax says “nothing special here, just reading a value”.
My code is clearer this way. It’s immediately obvious to readers that these message sends are barely method calls; they’re meant to be read as simply getting a value, while the square-bracket calls do work or take some action.
Brackets indicate a command; dot syntax means a value. Mixing these two intentions by using brackets for everything makes the reader work harder; they must mentally distinguish between “the action being made here” and “the values used to enable this action”. With dot syntax, the intent behind a message send is clearer and the code is simpler to read.
Searching
The one semi-valid argument for avoiding dot syntax for non-properties was that mixing syntax makes searching for usage of a given method harder.
This argument is no longer valid, for several reasons:
It was unreliable anyway
Programmers who share my opinion were using -count with dot syntax years ago, and so you had to search for both ` count] and .count` anyway.
iOS 8 and Swift
Many property-like methods, like -count, were changed to @property between iOS 7 and 8, meaning you really have to search for both syntaxes even if you’re only working with programmers who have always been strict about dot syntax.
These changes were made for better interoperability with Swift, where—again—you have to search for dot-syntax-style usage of any method, not just property getters.
Xcode can find usages
Xcode has a “find usages” tool that mostly works. You should use it to replace or at least to supplement your searches.
(Update!) Autocomplete
Brian Capps asked, what about autocomplete? Misspellings are very real, and Xcode’s autocompletion is (usually) useful, but it won’t work if you’re trying to use dot syntax for non-@property methods.
Most time is spent reading, not writing, code. Clarity of intent in reviewing code trumps convenience while first writing the code; and dot syntax communicates intent.
But there’s no denying code completion is helpful. Sometimes I just write without it, but to be honest, I’ll happily write brackets and then edit them out in favor of dot syntax.
Either way, I end up with code which clearly expresses my intent.
That’s all.
I use dot syntax to better express my intent when calling methods which meet the criteria laid out above. You’re going to have a hard time changing my mind.