Objective C’s Verbosity
I enjoy the verbosity of Objective-C; those long method names and variable are fun to read (and fun to write with auto-completion turned on). Recently, I accepted that fact that some people like to limit code to 120 characters (or even 80 characters). Code lines this short are predictable at small window sizes, a big advantage in small terminal windows. Even though I’m writing code in XCode on a 27” iMac, I thought I’d give this a try.
It turns out that Objective-C formatted this way starts to look like an unreadable pile of mash. What I immediately noticed is that I rely upon the long method definitions to break apart my code. Using a line limit makes it harder to distinguish sections that previously were quite pronounced.
I’ll admit I was a little disappointed to go back to long lines, so I decided to do some investigating. I thought, “Lets see what any famous open-source project does in their code.” Moments later, I was on the Chameleon GitHub page and to my utter surprise—the code style had no line limit at all.
I hit up @BigZaphod (the primary author of the Chameleon project) on Twitter to see what he had to say about code formatting:
@bentford No one has ever mentioned it. :) My limit is basically “size of my window” but it doesn’t really bother me much.— Sean Heber (@BigZaphod) January 24, 2013
I’m happy to report that I went back to my old style. I’ve changed it up a bit and try to keep long code lines to a minimum. In Objective-C, it makes sense to let those long lines be.
It’s a nice feeling to gain confidence in a decision you’re not sure about simply by asking a respected peer.
List of opensource projects and their styles
Sharekit (mostly does not):
Some Limits, Some Not
Three20 limits to 100 characters by lining up colons. But also uses
/////////// to signal breaks in methods.