My New Coding Style

By Deane Barker on August 13, 2006

Differences in the “standard” coding style from language to language frustrate me. I get irritated that I have to change styles to fit in with the accepted norms for different languages.

Traditionally, some use variable names with_underscores, some MixedCase some mixedCase with the first word uncapitalized, some use tabs, some use spaces, etc.

I can code semi-fluently in six or seven languages, and I get tired of having to remember what the accepted style is for particular language I’m in. So, at the risk of looking like a complete boob, I hereby declare my independence from other people’s coding styles. Specifically:

  • All my variables will now be MixedCase. This includes CSS classes as well. Functions too, for that matter.
  • I will use tabs with wild abandon (when you think about it, tabs are an abstraction layer for indenting — they just tell the code to what level it should be indented, not how far it should appear to be indented, like spaces do)
  • My brackets will always be on their own line, K & R be damned.

(Of course, I can do this because I am master of my own programming universe. Let me throw in this disclaimer: if my company goes belly up one day, and you interview me for a job, and then you come read this post — rest assured I will comply with whatever standard your great and benevolent organization wants me to, kind sir.)

I had a Skype conversation with Adam Kalsey about this a few weeks ago. He did bring up the point that MixedCase PHP can be hard to do in vi because the first letter gets lost against the dollar sign. While I respect his point, I don’t see it as a huge issue.

Ken Arnold talked about this in an essay in Spolsky’s “The Best Software Writing.” He said this:

For almost any mature language (C, Java, C++, Python, Lisp, Ada, FORTRAN, Python, Smalltalk, sh, javascript, …) coding style is an essentially solved problem, and we ought to stop worrying about it. And to stop worrying about it will require worrying about it a lot first, because the only way to get from where we are to a place where we stop worrying about style is to enforce it as part of the language.

I agree. Enforce coding styles at the compiler level. Your brackets are in the wrong place? App doesn’t compile. You used an underscore in a variable name? App doesn’t compile. The specifics of the style doesn’t so much matter, just that the style is enforced, everyone has to use it, and we can all stop arguing about the best way to do it.

I feel the same way about this as I do about school uniforms. My kids aren’t in school to look fashionable. They’re there to learn, so make all the kids dress the same so we can remove that distraction completely. Same goes with coding: we don’t write code to use our own coding conventions, so let’s make everyone do it the same so we can remove that distraction complete.y

There’s precedent here, of course:

  • In Python, control flow is dictated by whitespace. You indent blocks, and that defines your control structures. (Although in the one instance I used Python, this made embedding it in HTML very…weird. Maybe that was the point.)
  • In Ruby, constants are ALL_CAPS. If you try to reassign a value to a variable in ALL_CAPS, the runtime throws a warning.

There’s a lot to be said for this, there really is. We waste too much time arguing about it, and there are too many problems when someone comes in and uses a wildly differing style on an existing codebase.



  1. In Ruby, constants are ALL_CAPS

    by convention – constants just need to start with an uppercase. class and module names are constants, but differ greatly from other constants, and so the ALL_CAPS convention has arisen.

    i like the idea that convention be enforced by a (pre?) compiler. it shouldn’t be that hard to write a couple of regular expressions to enforce a coding style, no?

  2. I’ve always been more of a mixedCaps sort of guy myself.

    One thing that always irked me was when people would start brackets on the same line as an IF statement…

    IF (a !=b) {
    cout < < "test";

    …for example. I have this compelling drive to always place associated brackets on the same indent level. I understand the logic behind the above usage (the bracket almost acts as the “THEN” statement), but it just looks funny to me. I worked with someone for an entire semester project with whom I agreed on nearly every formatting convention except that one, and it was always an unspoken battle that we’d revise each other’s formatting to make it consistent.

  3. I have this compelling drive to always place associated brackets on the same indent level.

    Yes, exactly. Exactly, exactly, exactly.

Comments are closed. If you have something you really want to say, email and we‘ll get it added for you.