Archive for August, 2005

Its all about style, baby

Seriously, people. You’d think we’d have learned this by now. Style is vitally important when you’re an engineer.

Now when I say “style” most engineers think about aesthetic stuff, like where they should put their curly braces. Why, I’m not sure. There are two basic camps here. Either the curly brace on the same line:

if( foo ) {

or each brace on a separate line:

if( foo )

I’ll refer to these as “humdinger” and “hootinanny” because calling them “style A” and “style B” is just plain boring.

Anyway, engineers will argue for hours if not days about which one is the One True Curly Brace Style. While this can lead to an amusing “Family Guy” type conversation, it doesn’t usually accomplish anything. Then someone, usually a troublemaker, will suggest a style I call “wazzat?”:

if( foo )

and the arguments will start anew. The truth is, it doesn’t matter. It simply won’t effect the user in any way. I’ve switched between “humdinger” and “hootinanny” when switching projects with no problems. It turns out humans are remarkably adaptable. Sure, I’ll ask God when I get to heaven which one is the One True Curly Brace Style, but right now, it doesn’t matter. (I expect to be told “wazzat?” was invented by Satan himself.)

No, when I speak of style, I’m talking about stuff that will actually effect the stability and quality of the product. For example, always initializing your variables as soon as you declare them.

A lot of engineers do this:

int i;
// go use i

I say that that’s incorrect and you should do something like:

int i = 0;
// go use i

I suspect that I wouldn’t get many arguments about this. Sure someone might say “well I initialize the variable on the very next line” or “I have rugged good looks, so uninitialized variables don’t effect me.” [1] The problem with waiting to the next line to initialize the variable is your fellow engineers (aka “those sniveling weasels”) are going to insert code between your declaration and when you use the variable. Sure it’ll start out with something innocent, but eventually someone will use the variable before you initialize it and pandemonium will ensue. I don’t know how many uninitialized variable bugs I’ve fixed in Dreamweaver, but its enough that its become a pet-peeve of mine. It concerned me enough to send an email to all the engineers pleading for everyone to initialize their variables.

So that’s it, right? Once an engineer learns about a coding style that will improve their code they immediately employ it. After reading this, no one will ever declare a variable without initializing it in the same statement. No one on Dreamweaver’s engineering team ever checks in code with uninitalized variables now. Right?

Well, unfortunately no. I was quite surprised to see the change notifications that rolled past after my impassioned message about uninitialized variables. Sure there were a couple of engineers who picked it up and even started cleaning up code as they saw it. But the surprising majority ignored my request. And why is that? Didn’t they care about the users suffering through crashes? Couldn’t they see the brilliance of my suggestion? Wasn’t I condescending enough?

Engineers resist change for a variety of reasons. First, change might imply they were doing something wrong in the first place. Some engineers hate to admit that. Typically, these aren’t good engineers in the first place, so I’ll ignore them for this discussion.[2] Second, engineers have strong coding reflexes. They typically aren’t thinking about the syntax of the language, but the logic they’re writing. As a result, its hard to add new coding styles to their repertoire. They have to stop and think “oh yeah, I need to initialize this variable immediately.” That slows them down and is sometimes skipped. As a result, the new coding style doesn’t become a reflex.

And that’s the key. The new coding style must become a reflex or it will be unused and the engineer’s code will not improve. When I’m trying to pick up a new style I have to type slower and think harder about what I’m doing. Also, if I mess up and don’t employ the new style, I force myself to go back and fix it immediately. A lot of engineers make the mistake of saying “oh, I’ll come back later and fix this.” No you won’t so stop lying to yourself. Its time for an intervention, Sparky. If you don’t start using a coding style pretty much immediately, you won’t use it, ever. You’ll forget about it. So slow down and start using the new style right now. Also, as you go through old code start “upgrading” it to use the new style. It will not only improve the code, but help you build your reflexes.

I’ve seen innumerable articles about various coding styles. Most are about the author’s personal preferences and what visually looks good to them. And that’s fine if that’s what they care about. However a good engineer has to be able to separate the wheat from the chaff. Fortunately, that’s easy; just ask yourself “will this improve the user’s experience?” If yes, then adopt the coding style immediately. If no, leave the trained squirrels to argue about how much space should go between an if statement and the first parenthesis.

Although its hard to argue that coding style is as important as selecting the correct algorithm or data structure, style is still vital. Its something that can be improved without too much effort. In fact, after it becomes a reflex its not any extra effort. Improving your coding style can improve your code and more importantly, improve the user’s experience.

[1] People with rugged good looks don’t seem to worry about much of anything. I’m not sure why.

[2] A dicussion on trained squirrels would take up an entire article.

Math is hard

[Note: This was the orginal post for my “professional” blog. It attempts to describe why I started a blog. It certainly wasn’t because I’m interesting.]

Or writing is hard, I should say. But “math is hard” is what one of my coworkers told me. I was trying to explain something technical (like how virtual memory works) when her eyes glazed over. I get that a lot. Anyway, she got some terms mixed up and said something like “so should I test the multiflange array for tacheon emissions?” Or something like that; I don’t really pay attention to the QA people. But her response to my laughter was “math is hard.”

Although math has never been all that hard for me, it did remind of what is. Writing. Being a software engineer I’m more used to communicating with computers in written form than humans. That means writing interesting specs or design documents or just communicating with coworkers is pretty difficult for me. Unfortunately submitting instructions via email to someone isn’t like writing a program to run on a computer. People don’t listen well and take exception to being called “buggy.”

Recently Joel Spolsky has been writing about the lack of good writing in the software engineering field. He’s asserted that good writing skills are essential to a software engineer’s career, and even compiled a book on what he considers to be good writing. Among his suggestions for engineers wanting to get better is something he calls “practice.” I decided to give that revolutionary idea a chance before Microsoft patents it.

So that’s the point. This is just practice. i.e. This is pre-alpha quality writing not meant to be used in a production environment. Use at your own risk, and keep all appendages inside the cart at all times.