What’s your level of code assertions?

Published on Monday, January 7th, 2008

Last year in November, Andy Hunt, of The Pragmatic Programmer and Agile Manifesto, was invited to speak exclusively to our company, and some things he said made me start thinking.

Andy seemed a bit tired and jet-lagged, to be honest, and maybe somewhat jaded from doing very similar talks about being pragmatic in your work. He did a good presentation, though, and two things he mentioned really stuck:

The Dreyfus model
Always use assertions

Let me take a moment and explain what they are.

The Dreyfus Model

The Dreyfus model covers skill acquisition and how people progress with their skill sets. The five levels are:

Novice: Needs to be told exactly what to do. Very little context to base decisions off of.
Advanced beginner: Has more context for decisions, but still needs rigid guidelines to follow.
Competent: Begins to question the reasoning behind the tasks, and can see longer term consequences.
Proficient: Still relies on rules, but able to separate what is most important.
Expert: Works mainly on intuition, except in circumstances where problems occur.

Thanks to Cory Foy for The Dreyfus Model experiment post.

Use Assertions to Prevent the Impossible

Assertions validate your assumptions. Use them to protect your code from an uncertain world.

The idea is to always use assertions to avoid any potential errors with your code, and avoid being stunned by a problem which you never ever expected to occur.

What are assertions?

Basically, it’s about making sure that things never ever go wrong. No matter how sure you (think) you are that something should never happen, or take for granted that certain dependency is available for your code, don’t. Just don’t. Call it Force Majeure, Murphy’s Law or whatever you want, but things will inevitably go wrong, sooner or later.

And when it does, that’s when quality plays in. Have you made enough and proper assertions to completely avoid it, or at least made the damage controllable?

Throughout all my professional life, in the IT business and others, people know that things go wrong. And tyeh accept it, to a certain degree. The key question is: what do you do when it does? The manner of handling problems can be the difference between a failing and successful business.

Simple examples of assertions

Let’s use JavaScript, the wonderful language that it is, to give an example:

// This is bad
document.getElementById("photo-frame").setAttribute("src", "vacation-photo.jpg");

// This is good
var photoFrame = document.getElementById("photo-frame");
if (photoFrame && photoFrame.setAttribute) {
	document.getElementById("photo-frame").setAttribute("src", "vacation-photo.jpg");
}

The second example is good because it’s about making sure that an element exists to begin with and that it supports the method you want to call on it, before actually executing it. Assertions, people. I guess you get the drift.

This goes for all code, of course, within small as well as large scopes. And I advise you to really find out why things might not work. Try and avoid code like this:

try {
	document.getElementById("photo-frame").setAttribute("src", "vacation-photo.jpg");
}
catch (error) {
	// This should never happen
}

How do we use this?

First, let me say that I’m a firm believer in intuition. Dealing with real-life problems and situations, intuition, or gut-feeling if you will, is very often they key to doing the right choice when faced with something hard. Your whole system, be it physically or mentally, leads and guides you with all the knowledge you have ever collected, to a true decision. Or, at least what feels true at the time.

But at the same time, using assertions makes a whole lot of sense, right? I’d say that the best route to go is using a lot of assertions in your code, but at the same time use intuition as a key ingredient for any major decisions. For instance, with many JavaScript libraries out there (DOMAssistant included) a lot of the basic assertions are made for you. But don’t let yourself get lazy. It’s your responsibility to make sure any kind of assertions are in place, be it through library code or your own.