Archives For Language Issues

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…  Continue Reading…

In my screencast of UIViewController TDD, I used an example of incrementing a counter and couldn’t help but give a slight aside: “We’ll increment it… ++count, instead of count++, please.”


I blame Apple for propagating poor incrementing style. Programming with Objective-C starts with the statement, “[Objective-C is] a superset of the C programming language.” But every example they give of incrementing a value uses someInteger++, ignoring the fact that C has two different increment operators!

  • Post-increment: count++
  • Pre-increment: ++count

The Wikipedia article Increment and decrement operators gives clear examples of the difference.

What performance impact will it make? None. The extra code for post-increment semantics is probably optimized away by today’s compilers. Even if it’s not, it’ll still have almost no impact. So what does it matter?

It matters to the reader. It matters because it shows a lack of familiarity with the language’s operators, which doesn’t fill me with confidence in your code. It matters because Objective-C Is Still C (Not Java!)

Say what you mean, rather than relying on side-effects.

Question: Do language subtleties really matter? Leave a comment below.

I sometimes talk to myself. Our classes often do. But there are a couple of places where doing so is risky in Objective-C: init and dealloc.

"The Self-Talk Solution"

This post is part of the Code Smells in Objective-C series.

Here’s something I see a fair bit in code for Objective-C init and dealloc. I’ll give a simple example. Can you tell what’s wrong?

- (id)initWithFoo:(id)foo
    self = [super init];
    if (self)
        self.something = foo;
    return self;

- (void)dealloc
    self.something = nil;
    [super dealloc];

Hint: It’s those self-dots. They have a tendency to lull people into thinking they’re simple assignments. But remember, dot notation conceals messaging.

Let’s avoid dot notation and try again: Continue Reading…

Dot notation for messaging isn’t just an Objective-C code smell. It’s evil, I tell you!

Update: I recently changed my mind! See my post In Which I Embrace Dot Notation…

Dot notation: 100% PURE EVIL

This post is part of the Code Smells in Objective-C series.

…OK, so that’s hyperbole. I do manage to coexist with dot notation in projects that have it. But I won’t write it myself. Here are 3 reasons I avoid dot notation in my code: Continue Reading…

Here’s the scenario: A bug is reported. But the bug occurs only on the latest version of iOS. On earlier versions, everything’s a-okay. Ack!

Has this happened to you? I’ve dealt with it a couple of times. You can stare at the code as hard as you want, and come up with various theories. But you won’t get far that way. Why? Because on that earlier iOS, everything works. You won’t find any glaring errors just by looking.

So how do you debug iOS-specific problems? What you need is a diagnostic tool. Over on the iPhone Application Development blog, I describe a method that’s helped me crack tough problems. See iOS Version-Specific Bug!

Question: How have you dealt with version-specific bugs? Leave a comment below.

We all use factory methods, a.k.a. convenience methods. We often write them ourselves. But there’s a wrong way, and a right way, to write a factory method for your Objective-C class. Do it wrong, and you cut off some features of Objective-C. Do it right, and you open yourself up to new object-oriented possibilities.

Big [self alloc] factory

Volkswagen Factory Wolfsburg/Germany” by Werner Kunz, used under CC BY-NC-SA 2.0 / Altered by Jon Reid

Let’s back up and review what we mean by a factory method. This is a convenience method that you invoke on a class to say, “Make me one of your kind.” (Some folks call this a “convenience constructor” which is odd to me, because the underlying mechanics are quite different from Java or C++.)

Factory method: The wrong way

Let’s say we have a simple class:

@interface Foo : NSObject
- (id)init;

To create an autoreleased Foo object, we’d write

    Foo *aFoo = [[[Foo alloc] init] autorelease];

But if you do this a lot, it becomes tedious and can clutter your code. So let’s create a factory method.

At this point, it’s tempting to copy and paste into the body of the new method:

+ (Foo *)foo
    return [[[Foo alloc] init] autorelease];

Looks fine. Everything works. So what’s the problem? Continue Reading…

How do you switch your app between a staging URL (for development and testing) and a production URL (for real world use)? I’ve changed my mind about my approach, because one size doesn’t fit all.

In 9 Code Smells of the Preprocessor (and Their Fixes), I originally suggested that instead of using the preprocessor, it would be better to use a plist. Here’s the preprocessor code smell:

static NSString *const fooServiceURL = @"";
static NSString *const fooServiceURL = @"";

I wrote, “Instead of defining these URLs in your code, treat them as resource definitions and place them in a plist, organized by type.” Continue Reading…

Do you have your C book?

Do you have your K&R book?

October 2011 saw the passing of giants:

Simplicity. Power.

  • Steve Jobs. You work with his toys everyday.
  • Dennis Ritchie, inventor of the C programming language, co-inventor of Unix. You work with his stuff everyday (but we forget that).
  • John McCarthy, inventor of Lisp. We use the descendants of his invention every day (without realizing it).

By his vested Interweb powers, Tim O’Reilly has declared that October 30 be Dennis Ritchie Day. In his honor, I wanted to write something that’s been bothering me about the way people are learning Objective-C:

Objective-C is still C !

As a programmer, your most fundamental tools are the programming languages you use. If you don’t know the tool, you simply won’t be able to express things with both simplicity and power. And while I’m glad for the sudden interest in Objective-C, I’m troubled that so many people treat it like some kind of bastardized Java. They jump straight into messaging syntax and Foundation classes, while bypassing the powerhouse that’s available to them.

That powerhouse is the C language. Continue Reading…

Code Smells in Objective-C

September 18, 2011 — 8 Comments

Code smells. I’ve mentioned “code smells” at work, only to discover that my coworkers didn’t know what I meant. It’s basically a diaper-changing metaphor: “If it stinks, change it.”

Code Smells

diaper” by beth darbyshire, used under CC BY-NC-ND 2.0 / added text

“If it stinks, change it.”

A code smell isn’t “awful code that makes you hold your nose.” Rather, it’s a simple indication that something may need to be changed. Quite often, you won’t notice a code smell until someone else describes it. This is what Kent Beck and Martin Fowler did in the Refactoring book: created a list of smells, and what to do about them.

Code Smells Specific to Objective-C

The book’s catalog of code smells relate to good practices of object-oriented programming. I’m going to start a series that is specific to Objective-C code smells. Here’s a tentative list to give you a preview:

  1. 9 Code Smells of the Preprocessor (and Their Fixes)
  2. #imports Gone Wild! How to Tame File Dependencies
  3. 4 Ways Precompiled Headers Cripple Your Code
  4. Dot Notation in Objective-C: 100% Pure Evil
    …or maybe not! I switched, see In Which I Embrace Dot Notation…
  5. Why Avoid Messages to self in Objective-C init

I think this’ll be interesting, and sometimes even controversial. (Dot notation, anyone?) So be sure to come back — subscribe to keep up with the latest postings!

Other resources:

Question: What common Objective-C practices have you encountered that you might consider code smells? Leave a comment below.