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

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: 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: Too Much Information

How many times have I seen this pattern in object oriented code? Public Class All members of the class are private All members can be accessed with accessor functions All members can be changed with modifier functions I hate to break it to y'all, but that's just a struct. The only thing you've done is add a hundred lines

Patterns: Comment Through History

Programmers are not unlike Dory from Finding Nemo, in that we have a limited memory. It seems like every time we sit down to code, and we are randomly struck by a lightning bolt of inspiration, we immediately lose it when we notice something shiny. That's an extreme example, sure, but programmers do have a

Patterns: Yin and Yang

How many programmers whine that C is dangerous because of memory leaks? How many programmers rely on IDEs because they can't keep track of how many layers of brackets they're using? All of this stress is easily defeated with a little bit of Eastern Philosophy. Yin: Beginnings In the binary unifying force of the cosmos, there are

Patterns: Creation and Destruction Stack

Virtually 100% of all memory leaks are preventable, assuming the programmer knows where to look. In many cases, the leaks occur because a programmer has failed to destroy what he has created, but it can become more complicated than that. Creation Stack: The Order Matters In many cases, we allocate memory as we use it, and