I don’t write about programming as much as I do other topics, but if you look at number of hours spent on something in a day, programming comes out at the top of my list. My day job has me writing iPhone apps, and my night job does too.

One topic that is a source of endless discussion amongst programmers is that of programming style. Just like you can have MLA style, the AP Stylebook, and the like, so too do programmers have a style to their writing. What we have to realize is once the code is written, it will forever be maintained — which requires reading it. Thus, style is important to aid readability, and no one questions that.

But everyone wants to question what the style should be.

And of course, my way is the right way.

Background

I’ve been doing this long enough (I’m not a graybeard just because my beard is turning gray) to know there is no One True Way®. As long as you have some sort of consistent style and you produce readable code that’s appropriate for the context (because yes, certain programming languages and toolsets will bring about different styles), that’s essentially what matters. Yet, we still have people persisting their style is the one way that all code that a project involves must be written that way. Why? To what meaningful end does this address?

Style guides that merely propose cosmetic changes are useless and ego-driven, IMHO. But when the style has purpose and actually works to improve the code itself, has solid reasons behind the choices? That’s different.

When I started out, I didn’t have style. No one does. You eventually pick it up as you write more code. My first formal endeavor was working as a developer of a then-popular C++ Mac framework called PowerPlant. When I asked about coding style, the Grew Dow (creator) said “mine”. 🙂  Basically, PowerPlant was Greg’s baby and if I was going to write code for it to be included in the official distribution of it, I had to make my code look like his. This was a lot more than just where the curly braces went, but a lot of other form and function choices too. IIRC, Greg taught me this:

bool x = false;
if (SomeTest()) {
    x = true;
}
return x;

Compare to this:

bool x;
if (SomeTest()) {
    x = true;
}
else {
    x = false;
}
return x;

The first is more readable, more compact code, and generates better code too. The end result is the same. Go with the first.

This was a matter of style, but it produced better code.

Braces

Over the years my style has changed. In fact, one change happened within the past year, and I’m pretty happy with it. It concerns everyone’s favorite debate: curly braces!

I started out with:

if (foo)
{
  DoSomething();
}
else
{
  DoSomethingElse();
}

Because whitespace is good. Thus why I didn’t like:

if (foo) {
  DoSomething();
} else {
  DoSomethingElse();
}

Because while compact and nice on screen space, it wasn’t as good on the eye because the “else” wasn’t in a column with the “if” (for visual scanning, since we sometimes will process the code in “blurry” visual chunks, not necessarily processing the actual code), and depending upon the complexity of the code, readability wasn’t always best.

I flipped flopped around for a while on this, especially since Cocoa coding brings a lot of its own conventions to the mix, which for the most part are well-worth adopting especially since some are imposed on you in order to make things work. My current style?

if (foo) {
  DoSomething();
}
else {
  DoSomethingElse();
}

I find this works better because there’s better visual chunking of the data, better organization. It helps to keep the code compact, doesn’t waste too much space, but yet still keeps some whitespace around. It’s hard to get a feel for this style in small code snippets, but when you use it all day in various bits of code, it gets vetted and I’ve found this works quite well.

Of course, do-while is still potentially weird. 🙂

Pointers

I still debate this one.

I think it’s clearer to say:

NSString* string;

than

NSString *string;

Because to me, it’s making the type clear. That is, this is an NSString pointer. It makes sense too when you look at function/method arguments, be it C, C++, or Objective-C, because you declare return types as such and arguments do not always need a variable name, just the type. Thus:

- (NSString*)foo:(NSString*)s;

is legit and correct.

The only place I find this breaks down is if you wish to declare variables with a comma:

NSString* string1, *string2;

So you have to do that. But I also think it’s generally bad-form to declare with a comma, especially since it gets really messy looking with initialization, and in general you should initialize your variables (at declaration time).

Spaces

Another style change I made was spaces. Or rather, spaces vs. tabs.

I always used tabs. I preferred tabs. It made editing a lot easier. I did set my tabs to 4 spaces, but I still used tabs. I hated people that used spaces instead of tabs because it made editing hard.

When I came to my current day job, the server side was being done with Ruby (and Ruby on Rails). Those guys like spaces, and using 2 spaces per tab. And so, the clash began. The then-lead on things asked us to just switch to using spaces instead of tabs (tho we could stay at 4 per), and I just gave in because it was easier. Because that really was the problem: mixed setups.

I recall back at Metrowerks, most people used tabs with 4 spaces per tabs. I think one guy liked 8 spaces per tab, and then there was another guy that liked 3. Yes… 3. That made his code really weird to look at when you opened it up in your editor, because things lined up really wonky. And so problems arose when you couldn’t really read someone’s code (back to that readability thing), and it was made worse when people with different tab settings edited the same file.

Basically, it became a huge mess once you left the ability to have a homogeneous environment and complete control over it.

Using spaces instead of tabs fixes most of that. You can’t fix if people use different substitution values (e.g. 2 per vs. 4 per), but you will still end up with consistent-looking code when you open it up in a different editor, because a space is a space.

But this made me realize why I resisted for so long.

Editors

Your choice of editor tool matters, and affects your style.

For example, with the spaces vs. tabs situation, I hated using spaces because if I hit tab too many times, now I have to backspace a LOT in order to delete all those spaces, instead of just a couple backspaces to undo what I did. Typing out code isn’t like typing out a letter or a blog post, because a lot of keystrokes can be for formatting and navigation around the code. So now to have to do all this extra work, it adds up in a day.

But now, I have an editor that is smart(er) about this situation. So if I have tabs actually be 4 spaces, I hit tab, the cursor “tabs in” but really 4 spaces were entered. And if I mess up and press delete, it will “untab” and delete the 4 spaces. Having an editor that is smart about such things really goes a long way, not just towards helping you write code, but helping you manage these sorts of style choices.

I would also add that the growth of screen size and resolution has helped a great deal. We aren’t using VT100 terminals limited to 24 rows and 80 columns, yet some people still cling to that standard. Why? Even our tiny mobile devices aren’t so limited. Granted, if you are in a particular environment that requires such constraints that’s one thing. But I primarily work on a 17″ MacBook Pro with a 1920×1200 screen; I used to work with 2-3 total monitors. We have the space, we should use it. Our eyes like to see a wide horizontal plane (thus why TV’s are widescreen and movies are wider not taller). Use that.

Thankfully Xcode is really getting better about these things. It’s taken a while, and it was really important for Xcode to be an awesome editor because the 3rd party editor road and integration/support was just not happening.

One thing that I’ve also given into is code completion. I didn’t like it because hey… what’s so hard about typing things out? Well, with some iOS/Cocoa API’s, it’s quite hard because the names can be VERY long and difficult to remember. So code completion has worked out to be a quite useful thing. But with that comes some imposition of style because someone had to decide how to insert that text. Xcode also allows some level of syntax-aware editing, where it can do things like auto-indent and the like. You have some control to pick and choose, and really once you tweak things to your liking the automation is nice. But again, there’s some level of imposition of style here that you cannot get around, especially if your choice isn’t represented in Xcode’s options.

Point is, your choice of editor can be a bane and a boon. In general, they should be there to help you write better code, more efficiently. But while doing so, it may require you to make some choices in your coding style. Don’t fight it, go with it. You might find some benefit to that stylistic approach. It’s worth the time to experiment with it, especially if it winds up improving your point of view, improving your code, or just giving you solid reasons and experience behind your rejection of that approach.

Editor Customization

And so, if the editor app matters, hopefully you can customize it to suit your needs.

I can touch-type, and I find it much faster to use keystrokes than to stop and utilize the mouse – I don’t have to (re)move (then replace) my hands. I know many people that use laptops as their primary computer, but hook up external keyboards and mice to it. To an extent I understand this, but again it’s about having good tools. If you use the keypad a fair deal, the loss of it on a laptop keyboard is a detriment. If your laptop’s pointing device merely moves the cursor on screen, an external mouse may work better for you (especially that scrollwheel). But I’m happy my MacBook Pro’s trackpad supports gestures, and I use them constantly to allow me to more easily move about not just my source code, but my whole computer. Taking advantage of Spaces (well, Mission Control – having multiple Desktops) is a big boon because I can put my communication (email, web, IM/chat) on one Desktop, Xcode on another, etc.. Gestures are useful.

Granted, I cannot customize the gestures so much as I can customize keyboard keystrokes. But thankfully I can and use that to help me efficient access the commands I use most.

Another customization has been the use of editor color. I like the solarized project for how it effectively syntax colors, but also is very easy on the eyes. Quite important when you’re staring at the screen all day.

Plugins are useful too, and this comes more directly back to my discussion of style. I found a useful plugin, VVDocumenter-Xcode. This is a simple Xcode plugin that with a simple keystroke inserts basic formatting for appledoc-style documentation (and I’m going to modify this for Xcode 5). Just like the endless debate about comments in code, there’s debate about how much documentation one should have. I am not always good about complete documentation (you get into a groove with coding, documentation becomes a secondary concern, then you don’t have time to go back), but a plugin like this makes it much easier. Furthermore, with some advances in Xcode 5, there’s even more incentive to document in a particular structure. I cannot comment further yet as Xcode 5 is presently under NDA. Nevertheless, documentation and documentation style is an important consideration in your coding practice. Because again, style is about making readable and maintainable code.

The Style of No-Style

Styles tend to not only separate men – because they have their own doctrines and then the doctrine became the gospel truth that you cannot change. But if you do not have a style, if you just say: Well, here I am as a human being, how can I express myself totally and completely? Now, that way you won’t create a style, because style is a crystallization. That way, it’s a process of continuing growth.

– Bruce Lee

My style is my style. It is what allows me to most effectively communicate. It is what allows me to best express my thoughts, in code, in implementing a solution to a problem. For me to use your style would get in the way of my effective communication, so why should I do it?

I look at modern programming teams. Typically they are comprised of many people of different backgrounds, and often these days, ethnicities and origins. I say this because not everyone on the team might speak English the same as you or as well as you. Joe speaks with a southern accent and phrasing, and Young-soo speaks more in Engrish. If we forced “1 true way” of speaking upon Joe and Young-soo, if we made them all speak in British English (colloquialisms and all), how effective would that be for the team? We’d never think of doing such a thing, yet it’s precisely what we do when we impose “1 true style” of coding upon a whole team. Does that really lend to effective coding? to effective communication and expression?

Or can we accept that there’s at least enough of a style, enough of a standard in place that allows us to get the job done with each member expressing themselves as best as they can? Oh sure, if we find ways to help improve our communication, we should improve (e.g. allow your style to evolve). Just keep in mind what a coding style is to be for, and work towards enabling the team to effectively express themselves and write successful code.

If you have no particular style, if you need to find some way to improve the team’s workings, adopting style guides such as the NYTimes Objective-C Style Guide can be useful. Even if you don’t need such a guide, consider what the guide has because there may be a new twist or technique that allows you to improve your code. For example, reading that guide reminded me about Xcode’s expanded support for literals and how BOOL isn’t quite what you think. If we can write better code, if we can more fully express ourselves, style is a benefit. Just keep it in such perspective.