Quality Coding

In Which I Embrace Dot Notation …

Dot notation is okay, after all.

There, I said it.

I’ve been a staunch opponent of dot notation. I saw it as obscuring messaging, and encouraging programmers to violate the Law of Demeter through chained dots. I went so far as to characterize dot notation as an Objective-C code smell.

So it may surprise you to learn that I’ve recently adopted dot notation in my code! Here’s how it happened…

Before I switched

I had two coding habits that struck some of you as peculiar:

  • Given a property, I preferred to access it through its backing ivar.
  • And of course, I didn’t use dot notation.

Some say, “Always use self-dot to access properties.” I didn’t agree, because if customized the setter or getter, it was easy to switch. No big deal. And since I didn’t want to use dots, calling

[[self prop] doSomething];

seemed excessive when I could simply do

[_prop doSomething];

KVO leads to properties

But then Eric Baker made that screencast of TDD using ReactiveCocoa. He took my MVC TDD screencast in a different direction. Instead of having the model post notifications when it changed, he turned much of my code into boilerplate, replaced by ReactiveCocoa.

I may try using ReactiveCocoa for a project, just to learn more. But here’s the key: ReactiveCocoa’s style of functional reactive programming depends on key-value observation (KVO).

The main reason I’ve preferred notifications over KVO is that I like using a separate methods to handle different aspects of the model changing. In KVO, all observing goes to a single method which then has to handle dispatching according to the changed aspect.

But what I didn’t know was that direct ivar manipulation doesn’t trigger KVO. If you want KVO, a class has to manipulate its own properties using the setters. So my direct ivar manipulation was effectively preventing anyone else from using KVO on my classes.

That’s no good. If you’re going to use one of my classes, I don’t want to cut you off from a programming tool just because I happen to code in a certain way.

Properties leads to self-dot

So “use your own setters” it is. And I’d rather not code one style to set a value, while using a different style to get a value. “Use your own getters” follows pretty naturally.

But eww, I don’t like

[[self prop] doSomething];

Suddenly I saw that “use your own properties” meant life would be cleaner if I adopted self-dot:

[self.prop doSomething];

And if I’m going to use self-dot… well, I may as well surrender.

Readability for the win

Dot notation is easier on the eyes. I’ve always admitted that. What I failed to realize before is that it isn’t just a matter of “aesthetics.” It’s more readable. And readability is super-important.

Somewhat related to this: dot notation is mainstream. By opposing it, I was going against the flow. I knew that, but it made me uncomfortable to make a screencast only to have people comment, “Why are you  directly accessing ivars?” So by adopting dot notation, I hope my code will be less distracting, so that you can focus on the principles I’m trying to show.

Dot notation: still watchful for LoD

I still keep a weather eye on the number of dots, staying sensitive to the Law of Demeter. Chained dots still smell of Inappropriate Intimacy. So more than one dot (where self-dot doesn’t count) makes me question why fiddling around with a property’s property is any of the code’s business. But that’s probably a topic for another day…

So there you have it. Dots, yay.

What about you: have you ever switched sides in a coding holy war? Leave a comment below.

About the Author Jon Reid

Jon is a coach and consultant on iOS Clean Code (Test Driven Development, unit testing, refactoring, design). He's been practicing TDD since 2001. You can learn more about his background, or see what services he can bring to your organization.

follow me on:

Leave a Comment:

Add Your Reply