[Note: Steve Maine has a wonderful post on "Jedi coders" that focuses on the ability of great coders to do great conceptual work - I consider this post to be a compliment to Steve's, but covering the more superficial aspects of coding. A great coder, in my opinion, is great from top to bottom - being able to work out an elegant solution to a problem isn't the same as being able to code elegantly, but I think both are important qualities of a great coder.]

I was driven out of the apartment early this morning by a malfunctioning furnace. The temperature within the walls dropped to approximately one eighth of (my body weight + my IQ) last night (figure that one out, you bastards), and I thought I'd set out for someplace warmer like the walk-in beer cooler at the convenience store down the street.

Got a little sidetracked, forgot about the beer cooler (hey - I am a bit hungover here), and found myself heading for the downtown Stumptown Coffee (free WiFi). On the way, I was watching the way people were behaving in traffic.

They were, if you must know, behaving like pigs. They were cutting each other off, not using their signals, driving too slowly, driving too fast, switching lanes where it wasn't legal, running lights, rolling through stop signs, and just generally making a mockery of the rules and regulations outlined in the Oregon DMV manual.

This got me thinking about coders.

At the last Portland Nerd Meeting, there was a lot of talk on the subject of "code aesthetics." We didn't call it that at the time because nobody had managed to be as pretentious as I was just now, but that's really what we were discussing.

We talked about casing, commenting, variable naming, and laziness.

I don't know about you, but when I drive, I generally try to do my best to follow the rules. I signal when I'm supposed to, let people in when it makes sense to do so (when I won't hold up 20 cars behind me to let one person pull onto the road), let pedestrians cross at crosswalks, stop at the lights, and so on. I might be totally off my rocker, but it seems to me that traffic jams, road rage, and other scourges of the traffic system have a lot to do with the general populace's inability to follow a few simple rules. I do my part to try and make life on the road easy, even if I'm having to work harder, and even when most of the people around me aren't making the same effort.

Not to sound like I'm patting myself on the back or anything (I have plenty of other posts in which I've done that), but I understand that the road doesn't belong to me, that I have to share it with other people, and that I have the choice to make their lives easier rather than harder (and harder on myself in the process). I don't get into my car, tear down the street, honk at people who have right of way, flip people off who signal to get into my lane, or anything of the sort.

I've encountered so much "paper bag" code in the past few years that it makes me want to cry. "Paper bag" code, by the way, is code that's so ugly that I want to put a paper bag over its head.

Here are some examples of "paper bag" code - this stuff is the equivalent of cutting people off on the road, running over pedestrians, and not pulling to the side when emergency response vehicles need to get through (a lot of these were brought to mind by Jason Olson during a very intense, very entertaining conversation):

This is a biggie for me. It might seem like it's a petty concern, but imagine that you're coming into an existing C# project and you see something like this:

    SomeVariableName.SomeMethodName();

I don't know about you, but my brain immediately causes me to believe that I'm looking at a static method call. When I'm coding in C#, I don't equate Pascal casing with instances of a type. Per the style guide, this is what I expect:

    someVariableName.SomeMethodName();

This makes sense to me, and probably would to the majority of C# coders out there, as well.

The danger of ignoring a rule like this is that you're going to confuse the hell out of the developer who's inheriting your project. I recently worked with some code like this, and five minutes into looking at it made the assumption, based on all the Pascal casing, that someone had put together about 500 libraries with nothing but static method calls in them. That's not cool.

On another note, during my recent move, one of the first things I threw out was the book "C# Design Patterns." Many of the examples were obviously just Java that had been "ported" to C#. This wouldn't have bothered me so much, but the author didn't even take the time to properly case anything, going so far as to leave methods camel cased as they were in the original Java examples.

Screw that.

How many times have you seen the following:

    // gets the user's first name from an instance of the user class:
    name = user.FirstName;

Yeah. Thanks for the comment, pal. I needed it, 'cause I'm TOTALLY FREAKING STUPID.

If you need comments like this, and if someone is actually paying you to code, then please drop me an email so that I can find out where you work and come in to perform what I call a Citizen's Firing. I realize that I lack the authority to officially relieve you of your duty, but that's a minor detail we'll worry about later.

There is some laziness that's OK.

Take this for example:

    for (int i = 0; i < 10; i++)
    {
        ...
    }

Is anybody going to have a problem with the variable name "i" here?

Possibly, but we're talking about a very short lived variable here, and I think that the uber-crappy variable name "i" is perfectly justified in this case.

However, take this JavaScript code that I saw recently:

    var t = this;
    var v = navigator.appVersion.toLowerCase(), u = navigator.userAgent.toLowerCase(), n = navigator.appName;
    var d = document;
    t.ua = new Object();
    t.ua.mac = (v.indexOf("mac")!=-1);
    t.ua.win = (v.indexOf("win")!=-1);
    t.ua.nn = (n=="Netscape");
    ...

I mean, c'mon - How much clarity did we trade for saving a couple of keystrokes here? Is it really that hard to type "this"? Or to name a variable "version" instead of "v"?

Crap, I say! That's some raunchy code. Check out the last line before moving on. Notice the triple-whammy of an insult with all the poorly named variables. This stuff makes my stomach turn.

Whoever did this, wherever you are, I hereby perform a Citizen's Firing on your lazy ass.

I would never pass something like this on to another coder.

Jason Olson brought up another great one during dinner.

Let's say that you have an variable called "factoryWall" (it's just an example, my friends).

For the sake of clarity, it's easy enough to type "factoryWall" for each call, right?

That's what I think, too, but evidentially some people would rather write something like "fctrWll" to save a couple of keystrokes. Never mind the instantaneous obfuscation of code that takes place upon doing this - milliseconds were saved by turning a blind eye to readability, maintainability, and a few other words that end in "ability."

I realize that some of you are ex-mainframe coders, but this is the 21st century, and times have changed. Looking at some mainframe code, I've determined that there must have been a great shortage of vowel keys back in the early days of coding, but they're in perfect abundance now. Use them! I don't know where all the new vowel keys came from, don't know who had to die to bring them to us, how many vowel key trees had to be chopped down to accommodate our desires, but don't let these sacrifices seem to have been made in vain.

These few examples just barely begin to cover all the ways in which you can, figuratively speaking, cut off your fellow coders. I'm sure there will be a few other pet peeves added in the comments list.

I just feel that if you really care about what you do, and if you really understand that other people will have to work with your code at some point, it's a fine thing to put in the effort to help make your fellow coders' lives suck a little less.