On Programming

I am often interested in how specific code works in different build configurations. In the case of a custom ASSERT macro, I want to make sure that it does not evaluate any expression in builds where it is disabled (i.e. it is 'compiled out'). The technique I use is the following:

Let's assume CHECK_EQUALS is a macro in your test framework that checks if it's two inputs are equal. ASSERT behaves as usual. Let's also assume, your build system somewhere defines ASSERTS_ENABLED in those builds where this is so desired. Here is some code:

What's happening here? The expression inside ASSERT contains code with a side effect. If the ASSERT macro is defined to do anything, the side effect is that a is being set to 100. The expression evaluates to true, and no harm is done. Otherwise a will stay at 0, in which case we can safely say that ASSERT does not evaluate the expression.

I have written a little bit more information in the About post, about what this blog is about (I can’t think of a way to put this with less about’s), and even a tiny bit about myself.

I have also changed the style by accident, and I forgot which style I used before. I will learn to like the new one in time.

Recently, I had coffee with a friend of mine who happens to be an excellent programmer. I asked him about that blog that he was supposed to start, and he said, “Well, I can’t seem to get comments to work with Zope. Can’t have a blog without comments”.

I have seen that a lot (also in myself, mind you). There is this tiny detail that is in the way. It is like a little dwarf with a plastic sword guarding the entrance to your kingdom. Yet it also guards you from entering it! Think about it. The detail can be fixed in a jiffy. In this specific case, use one of those free comment services until you get your own system to work. I suggested that. He shrugged and gave me a “Yeah, but..” kind of body language. But … what? I believe the completion is something like “Yeah, but .. what if”. What if I don’t write often enough what if the stuff I write does not interest anyone. What if, therefore, I lose what I think is the building blocks of my identity and hence the reason I exist?

Kick the dwarf. Then move forward just one inch. See how it feels. The next one is just around the corner. It’s not a big deal.

What are your dwarfs? Have you encountered some lately? Do they have names?

When I sit down to work, whatever I have previously decided to do next needs to grab my attention as soon as possible. Otherwise my attention begins to wander while desperately looking for my To-Do list. In the case of programming, specifically using Test Driven Development, I try to leave my desk with a failing test or a compiler error. Sometimes tough, everything compiles fine and I can’t figure out what the next failing test should be. So in this case, I tend to do the following:

Before I take a break (and I do take a break every 30 minutes, if I don’t get too obsessed), I paste the description of my next test verbatim into the place in the code where it will be implemented. So, in, say, C++, using your favourite test framework, it would look like so:

Next time I start the compiler it will alert me very vocally that there is an error. Which is actually the next thing I have to do. My brain is immediately engaged and I have a fighting chance to keep it enganged for the coming 30 minutes.