Bracket-notation syntax

I don’t agree with The Big Nerd Ranch’s philosophy. When I teach, I make sure to mention the bracket-notation added to C by Objective-C. Then, I make sure to tell the students never to use it ever, ever, ever again. Buy why? To keep our code consistent and maintain readability.

The Intent of Code

When we look at well written C code, we can tell exactly what is going on by glancing at it. That’s the power that C gives us. If I want to take a drink of water while doing a cartwheel, I call the function:

drink(water, TRUE);

We know exactly what that means. There is no room for interpretation. It is pure, simple, and good, just as Jesus intended.

Then comes Objective-C…

Objective-C comes along, sprinkling diabetes-inducing syntactic sugar all over our code. We wind up having to read code like this:

x = [foo value];

What is that? Can anybody interpret that? Of course not! That’s because the compiler could translate it into a call to any one of the functions objc_msgSend, objc_msgSend_fpret, or objc_msgSend_stret. But we have no way of telling which one! It’s impossible! For all we know, the compiler just picks one at random!

It’s incredibly confusing, which is why I recommend that students exclusively call those C functions directly, so there is no doubt about which one is being called. That way the code is readable.

But I’m used to Smalltalk. Bracket notation looks like I’m at home!

You are not at home. You’re in the forest, and wolves are trying to kill you.

Apple uses it in their sample code, though!

That’s right, they do. But should you really be trying to emulate Apple? Have you heard about the App Store review process? They are totally incompetent and can’t do anything!

In the end, there is a wrong way and a right way to write Objective-C code. I will not say that using brackets is wrong, even though I tell my students never ever to use it. Is that confusing? Not as confusing as brackets are.