CTags: Lightning Fast Project Editing Made Easy

What's the fastest way to get from a function call back to its definition during the editing process? If you're using something like Notepad or an IDE, the answer is usually to search for the file containing the function, open it, and search your way down to the definition. Unfortunately, if you want to

Quickie: Configuration Headers

We all know (or at least we should know) that we can use #define to create macros that replace names with values during the preprocessor phase of compilation. Sometimes, it's very important for us to have the ability to change large amounts of code very quickly, because we have a new size limit for

Debugging Pro-Tip: Malloc() Errors

On Friday, I spent a number of hours trying to run down an error in a fairly substantial piece of code. All I really knew was that I kept getting an error that said something like: *** glibc detected *** ./my_program: malloc(): memory corruption: 0x0000000002296980 *** When I pushed this piece of code through gdb, I

Cleaning up – Comment out old code

If you've spent any appreciable time in the programming world, you've probably reorganized your code any number of times. When I'm writing code, I usually slap things out as I think of them, resulting in code that (while easy enough to read) defies the principle of unity. You'll see me write things like this: [c] int

Patterns – Prototypes and Optimization

The hardest interview I ever had: someone told me to go up to a whiteboard and solve a programming problem, in code, optimally, on the first try. It's a basic fact of our field that we iterate toward the final product. Not unlike a sculptor bringing the David out of a piece of marble, we

Patterns: Boundary Check

A wise quote: When it goes without saying, someone should probably say it. This is one of the better known patterns out there, but it still bears repeating. The boundaries for integers When you're working with a range of integers (for example, human age range could be between 0 and 135), we have two obvious boundary points

Patterns: Names as Documentation

While it's usually less of a problem in C, in my Java days I saw any number of functions with names like solve or act. These functions were usually overloaded, so that solve meant one thing for integers and a wholly different thing for strings.

Patterns: Error-oriented code

In 99.9% of cases, programmers spend most of their planning and initial coding creating the program that they want. They then spend twice as much time adding error-handling code to the original program, because they forgot that things can (and often do) go wrong. This is happy path programming, or success oriented code. Error orientation We notice

Patterns: Return values should mean something

I don't know how many hundreds of functions I've dealt with with either a void or boolean return type. While a boolean return type at least tells us whether the function ever completed properly, a void return carries absolutely no meaning. Where's the debugging or error-handling value in that? Constructors Constructor functions take a number of