Speed of Light

Sins of a Modern Objective C Developer Community

My friend Ash Furrow recently published an article entitled “Seven Deadly Sins of Modern Objective C” in which he lists grievances committed by programmers new and experienced alike who use outdated or incorrect methods of Objective C development. This article struck a chord with me, but not for good reasons.

The article begins with the bellicose proclamation:

If you code Objective-C, this is going to offend you and that’s good. If you aren’t offended, then you don’t care, and that’s bad.

I disagree with both statements and the conclusion. A list of common incorrect or outdated patterns of Objective C should make for an enlightening and educational read — it should not be looking to pick a fight. The original version of the article, which was painfully and profusely peppered with profanity has since been revised with less reviling language, but the harangue remains otherwise intact.

The so-called “sins” are hardly egregious, and few of them relate directly to Objective C anyway. Properly ordered, they are:

  1. Giant .xib files. These are interface files and not part of the language.

    Nonetheless, many novices will use this technique, which will use too much memory and suffer from slow loading times when the xib is read in. Experienced Cocoa developers know this already, but new programmers are probably not aware creating different views in the same file is hazardous. However, explaining this in an “offensive” way doesn’t help anyone.

  2. Not Using Dot Syntax. This sin has to do with a syntax introduced with declared properties in the Objective C language. He writes:

    Now that we’ve covered a sin common with newbies, let’s tackle one that’s common with Objective-C greybeards.

    Tossing out “Greybeards” is rarely a successful method of much more than grabbing the attention of a developer who likely knows a lot about a programming language, and it sure doesn’t encourage said programmer to pay much attention to any forthcoming arguments.

    Get with it, old timers! Dot syntax isn’t just The Way Of The Future, but it has other benefits, too, like not alienating all your peers and great compatibility with ARC (what’s that? You don’t use ARC? Jesus…).

    Again, this does nothing but inflame when instead the intent should be to inform. Just telling an experienced programmer this is “wrong” is a dogmatic solution. Any experienced programmer will immediately respond with that lovely three-letter word we need to hear more of: “Why?” The article provides no answer for that question.

    I agree with using dot-syntax for properties (which I’m assuming Ash is also advocating, as opposed to using dot-syntax for any old method), and when I explain this to other developers, I use Brent Simmons’ line of reasoning:

    Yes, I know it doesn’t matter to the compiled code, but I like having the conceptual difference, and the syntax reinforces that difference.

    And while you might not like dot notation — or you might love it and want to use it for things like count that are not properties — I ask you to remember that cool thing about Cocoa where we care about readability and common conventions. […]

    Say I’m searching a .m file to find out where a UIImageView gets its image set. Knowing that image is a property, I search on .image = to find out where it gets set.

    If I find nothing I start to freak out because it doesn’t make any sense. […] I know that image view displays an image, and I know the image is set somewhere in that file — and I can’t figure out where.

    And then, after wasting time and brain cells, I remember to search on setImage:. There it is.

    Brent says not only what he thinks you should do, but why he thinks you should do it too.

  3. Too Many Classes in .m Files. This one is pretty straightforward but I also feel like this isn’t something a beginner will do too often, as the standard Xcode behaviour is to generate two files (*sigh*) for every class. It’s possible that this is a common beginner problem but I haven’t witnessed it. Either way, Ash is right here. Jamming extra classes in an implementation file is not OK unless those classes are helper classes to the eponymous file class.

  4. Not Testing With Compiler Optimizations. Agreed, but I don’t feel like this is a common problem because in the general case, you develop under the assumption these optimizations are not introducing bugs. That’s the agreement you make with the compiler. But if you’re getting crashes in your released version, this is a great place to look for mistakes.

  5. Architecture-Dependent Primitive Types. The simple truth is, despite all the stylistic implication, the modern Cocoa APIs use these types, so if you don’t use these types you’re risking a loss of precision and you’re guaranteeing yourself a loss of abstraction.

  6. Unnecessarily C APIs. This sounds like more of an issue with Apple’s code (and I agree) than it is with other third-party code.

    Listen, guys, it’s the twenty first century. Don’t use C anymore unless you have to. It’s rude.

    But why? I would say avoid creating new C code in Objective C projects because function calls are less expressive of their meaning (see a previous post about the advantages of Objective C-style syntax). A message send gets compiled into an objc_msgSend()-like C call, anyway.

  7. Not Using Automated Tests. Finally, an accusatory rant on why you don’t test properly:

    Do you unit test your Objective-C? No, you probably don’t. Do you have automated UI acceptance tests for your UI? Nope. Do you have any kind of continuous integration set up? No, you don’t.

    I don’t understand what is wrong with the Objective-C community that it continuously eschews any form of automated testing. It’s a serious, systemic problem. I think I might know the cause.

    It’s neither useful nor encouraging to berate a group of programmers about any of these “sins”, but this one is more troubling than the others because Ash goes on to rationalize (likely correctly so) why many Cocoa developers don’t unit test: because our tools are crummy.

    I’ll agree the tools are crummy, and in part because of this our community does not tend to properly automate or unit test our code. But shaming isn’t the path to fostering better methodologies and habits. Shaming leads to dissent and applies a hierarchy over our community. It leads to superiority and inferiority complexes which further divide our fellow members and discourages open discussions for improvements.

I don’t mean to pick on Ash, because he’s a friend of mine and a damn intelligent (and charming) one, at that. But I do mean to pick on a trend of internet snickery, a lambasting of fellow developers with the surface intent of “criticism”, but which really comes out as harsh or just plain mean behaviour that doesn’t help anyone improve what they’re working on.

My point isn’t just that it’s rude to be inflammatory, or that being inflammatory is a cheap way to wrack up page views, or that being inflammatory reflects poorly on the author. It’s not helpful to beginners because it makes them feel stupid and it gives off an elitist vibe from the author. It’s also not helpful for experienced developers, who are confident in their skills but who could use some updating in their habits, because the inflammatory style is used in stead of providing actual reasoning of why these sins are something to be avoided. Being cussed out about bad habits doesn’t convince anybody of anything.

We developers are notoriously bad at socializing and I believe it’s one of the things severely keeping our craft much farther behind than it ought to be. We’re wonderfully intelligent people, but we’re nearly incapable of having open discussions to improve our craft. The idea of actual, constructive criticism seems farfetched to most developers, and it’s so much easier to shit on somebody else’s work. That’s not how progress is made and I believe this is one of the reasons we’ve been collectively spinning our tires since 1984 (see also Gabe at Macdrifter who shares similar thoughts on Daring Fireball-esque impersonations).

Next time you feel like mocking another developer for his or her lack of skills in a certain area, stop yourself. Talk to the person and explain to them why you think something they are doing is incorrect or how it could be done better. This way, you don’t come off as a jerk, and the other developer learns something new and improves. And I’d be surprised if you didn’t learn something from the experience, too.