Subscribe to
NSLog(); Header Image

Coding Conventions

I stumbled onto this post on coding conventions at a great time: I spent quite a few hours yesterday poking around PulpFiction's .h and .m files looking for quickie things to fix, comment, or otherwise KISS. My personal coding style closely mirrors that espoused at the page above, but as I looked through our code, I realized that we're not even very consistent amongst ourselves:

if (menu == nil)
    menu = [self menu];
// We ought to select the row that was right-clicked on just now...
// Select only if there's a row at that point and not already selected.
if (row >= 0 && ![self isRowSelected:row])
    [self selectRow:row byExtendingSelection:NO];

They're both one-line ifs! 🙂

Anyway, if you want to have a unified software development team, I think that it's important that every team member be comfortable with or at least tolerant of the coding conventions of his teammates. I've seen more than a few CVS battles start with one very simple command:

cvs commit -m 'reformatted code'

P.S. One rule about which I'm not very flexible: use TABS! Spaces suck.

11 Responses to "Coding Conventions"

  1. They have been pounding the coding standards stuff into my head for the past 16 weeks. Luckily, I am the one that knows what I am doing in my group projects, so they have to follow my standards. 🙂

  2. The trouble with tabs is that they do different things in different editors and on different platforms. Code using tabs may look well formatted to you, but to some guy using VI on an Irix machine it is completely illegible.

    At our CVS repositories at work, I actually have a Perl script that is run from CVSROOT/commitinfo that checks for tabs inside of source files and will fail the commit if it finds them.

    Pay your money, take your choice though. 🙂

  3. Tabs would be okay if everyone was consistent with them, but some editors seems to like to do:

    (with tab set as 8 spaces, I suppose)

    (4 spaces) 1st level

    (1 tab) 2nd level

    (1 tab 4 spaces) 3rd level

    Reading code like this in an editor that doesn't have the tabs set just right is maddening. That's why I'm strictly a spaces person - 4 spaces works for everyone, no matter your editor.

  4. Most editors allow you to set your tab width, which makes it easier to cope with. I have all my various editors set to use a tab width of 4, which is fairly comfortable to use. I would rather hit the tab key once per indent than the space key 4 times to get the same indenet, not to mention outdenting at the end of a block.

    I agree with the statement that software development teams need to be comfortable with eachothers coding styles. If it's in a commercial project, I would insist everyone follow a given style that's agreed upon up front. I've seen some nasty fights over re-formatted code as well over the years, and they are a waste of time. Having everyone following the same coding scheme though does tend to make everything more productive in the long run, to say the least.

  5. Well, since everybody likes to throw in their 2 cents for the tab debate -- I'm a spaces & tabs guy. I use tabs strictly for block-level indentation, and spaces after the tabs to align function/method parameters that are too long for one line.

    It works for me (tm).

  6. I was a braces on their own lines guy, then I went on a tour of Access (now owned by Microsoft, maker of the Links golf game) towards the end of my first year of high school C++. (Their head programmer for Links lived in my neighborhood so we went for boy scouts as a career night). Anyways it mostly turned into just playing the golf simulator, but I got into the brace debate with this guy after he showed us his workstation that had a screenful of code on it. After that, though he hadn't convinced me of anything, I had to write the biggest project for that class a simple object oriented bank program that had to do dynamic memory allocation. Well our programming lab was mac 5200s and we had to run at 640x480 so the teacher could see everything on our screen should they need to 'spy' on us from their computer. I tried it out just cause I was having a hard time going back and forth making every hard return count. I've done it with the opening brace at the end of the line ever since.

  7. Background reading:

    I disagree with his conclusion. Converting tabs into space-runs is a lossy transformation of my intent (one tab==one indentation, I don't care how it looks in *your* editor). While I view tabs as noncommands, I also view them as nonliterals. Different folks have different views, which is the crux of the problem.

  8. Yeah, wage the holy tab war! I'll guess we will never work on the same code, cause my first rule is: no tabs, just spaces. I need full control over the indentation (cause i sometimes do some really wacky alignments), and can't stand it that the code might look different in other editors. And of course, the main argument: It almost always happens to get mixed, and there nothing more crappy than a source file with some lines tabbed and some spaced.

    Dave: most editors can indent spaces via the tab key, if yours doesn't: use SubEthaEdit 🙂

  9. I have nothing against the tab key itself, just the tab character. I have my tab key set to add 4 spaces in my editors.

  10. I'm of the opinion that coding standards are a good way of preventing a lot of aggravation in a team. If there is a rule then there is no argument. Plus a standard let's you get into the groove quicker.

    I agree that skilled developers should be able to cope with different styles but sadly that's not the case. We have a couple of guys in my team that can't cope, funnily enough they are the youngest members. They are also the whiniest. If they find a brace out of place it's half an hour of productivity lost while they bitch about it.

    As for tabs and spaces, if you ever intend your code to be viewed anywhere else but your box, then spaces is it. Do it for your own vanity. There is nothing worse than looking at your own beautifully formatted code on someone elses computer and it being a pile of misaligned poop.

  11. I personally prefer tabs to spaces, it makes it a lot faster when using the arrow keys to navigate (because I'm not going to learn a bunch of control sequences just to move the cursor back an indent).

    Besides, I don't care if some person using vi on IRIX can't see it, chances are I'm not writing code for them (and I'm sure they have a very active interest in Cocoa programming, appologies to anyone using vi on IRIX that is).