Making it easy to spot mistakes

I just read an interesting article by Joel about writing code that makes it easy to spot mistakes.

The thing I like about his article was the bit about liking things that assumed human programmers are infallible and things that make mistakes easy to spot are a Good Thing. That’s what I’ve always liked about using static typing when dynamic typing isn’t needed. If the compiler can ask me whether I really meant to cast that custom business object to a double that’s one less mistake I need to worry about missing as I scramble to finish the project before the release date. If the best programmers in the world with twenty years experience working on high profile projects make mistakes (anyone remember the mars lander?) I’d have to say that the rest of us are probably going to let the odd mistake slip through too.

Mistakes are a funny sort of thing to talk about. You talk to some people about making mistakes and they’ll look at you funny and tell you that their code always compiles and runs properly first time. I don’t want to make it sound like my code’s full of errors (it’s not) but I think it’s much more useful to talk about mistakes and think of ways to minimize them than to pretend they don’t happen.

I think that’s what I like about some of the XP stuff I’ve been reading lately. The emphasis isn’t so much on getting upset about making mistakes (which is something that only comes through practice, which generally means actually making mistakes and then learning from them) but making them easy to see with things like unit testing, pair programming and small iterations.

I’m still not a fan of Hungarian Notation because I think that it makes code read less like English and I think the type of information that Joel’s talking about tends to be the less important than the second part of a hungarian variable that tells you what the variable is actually about. My disagreement’s just about the way hungarian says you have to put this information at the beginning of the variable rather than wherever it makes the best sense. I’d also say that the programmer probably needs to be able to decide which information is the most relevant because three or four coding conventions later you end up with variables that are like a hundred characters long and totally unreadable.

I don’t know if I agree with what he says about exceptions. I generally like exceptions because I think they let you flag when something unusual or wrong has happened without getting in the way of the main stuff that’s happening. It can be difficult to see the logic of the main program if your code has to specifically worry about everything from a user requesting an object that’s not in the database to the computer you’re connecting to being crushed in a freak earthquake.

It’s also a good opportunity to give the person using your code good information about why things have gone wrong. If you’ve checked for something in your code and thrown an exception because something didn’t come up to scratch, chances are you’ll have a pretty good idea what’s wrong. If you tell the calling code why it’s wrong (rather than saying something like “null is null” or “unspecificed exception”) then it might actually help the person who has to deal with it figure out what’s wrong.

I guess that probably makes me one of the people who love exceptions and hate hungarian notation that he warned to stop reading his article before he got to those two examples, but I liked his analogy about the baking machines and I thought his overall point was a good one even if I don’t totally agree with the examples.