The nice thing about this approach is that debugging can be turned on or off easily at compile time. However, my experience has been that it leads to a lot of typing, and seeing too many macros in the middle of code makes my brain explode in a fiery rage. So, I figured that if I wrapped my prints in another function (I called mine ‘log’ and ‘error’), I could avoid this whole mess and keep my sanity. I’ve done this with a number of other projects in other languages, but I had to learn some magic to do it in C.

Lesson Learned #1 : Variable arguments. It turns out you can define functions that take a variable number of arguments with va_list (from ). You define such a function:

void log(const char* fmt, ...) {
va_list args;
va_start(args, fmt);
...
va_end(args);
}


Lesson Learned #2 : However, from what I can gather, you can’t just inject printf directly into this. However, having anticipated this, there is a set of functions designed for cases like this: vfprintf, vprintf, vsnprintf, vsprintf. The ‘v’ stands for va_list (variable-argument list), and you can use them just like you’d expect:

void log(const char* fmt, ...) {
va_list args;
va_start(args, fmt);
fprintf(log_fd, "NOTE : ");
vfprintf(log_fd, fmt, args);
va_end(args);
}


The thing I like about this approach is that you have control over how log messages get printed in one place. So, for example, if I provided another function, setLogFD, then I could easily just set the file descriptor where all log messages get printed. So easy! Something I’ve used this for in other instances (especially servers) is to also inject additional information like a timestamp on every message. So, when I call:

log("Some event '%s' just happened.\n", event_name);


Then I automatically get “NOTE : ” and maybe a timestamp prefixed on that message. Which make code look clean, and adds a great deal of functionality. I actually added another function error(…) that prints to a different file descriptor in case I want to suppress debug messages, but no error messages. For additional layers of debugging, you might do something like this:

void log(int level, const char* fmt, ...) {
va_list args;
va_start(args, fmt);
FILE* fd = my_log_files[level];
fprintf(fd, "NOTE : ");
vfprintf(fd, fmt, args);
va_end(args);
}


This way, at startup, you could easily set some of the file descriptors in my_log_files to stderr and some to point to /dev/null or otherwise dissolve into the ether.

Hairs is pulled, teeth are gnashed, and eyeballs strain, scouring line after line. You try to convince yourself that your algorithm is correct, and that each line of code is justified. And yet, it still gets the better of you.

After perhaps eight hours, you swallow your pride, and ask a trusted friend to take a look. Often the very act of explaining things to another human being is helpful, but sometimes you both have to dig into the code. Maybe a third friend happens upon the two of you, and joins in.

Then, a light bulb goes off. If you’re lucky, it’s a massive structural change that’s required, but sometimes, it’s a single line, or a single word or character, and you suddenly find yourself embarrassed. But do not be. Every programmer I’ve ever met, no matter how qualified has run into these problems. Still, I find it easy to doubt my competence afterwards.

There are rare and beautiful moments when not only does code compile on the first try, but it runs as expected. Few and far between, cherish these when they come.

This is all inspired from a recent bug I tracked down. An embarrassing one. Sure, had I read the 350 or so pages of the OpenGL ES 2.0 specification, I may have caught it earlier, but this was one of those times when it was a single word that had to change. I tell myself that I won’t keep making these kinds of mistakes, and with each conquered bug I gain a tool, an experience point, and that’s what makes one’s craft.

I’ve looked at the time I spend debugging, and I’ve noticed that the time it takes to solve a bug can often be reduced by leaving the problem for a bit. Taking a walk, getting a cup of coffee, or sometimes watching an episode of Arrested Development. The desire to find and fix a bug is a siren’s song – nearly impossible to walk away from, but often a bad idea.