Programming – Jesse Bollinger

Too much fixation on fence-post issues inhibits creativity.

For a long while now I’ve noticed a very common recurring problem that seems to predominant as a frequent cause of both inhibited creativity and poor outcomes. Specifically, I am referring to the widespread tendency in many fields of study (but especially in computer programming and other technical fields) to focus so much on trying to ensure that every slightest fence-post issue is fully handled in all conceivable cases that it greatly impedes one’s creative and intellectual flow and in effect gives oneself tunnel vision. Such circumstances also often seem to tend to suck the fun out of projects and contribute to burn out as well.

I think this is actually also connected in some way to the moderately common prevalence of a certain kind of dismissiveness towards simple user interface problems that are easy to improve but nonetheless unfortunately neglected. All too often there will be some trivial aspect of how a piece of software (or other interface to something) works which if improved or corrected would yield a great improvement in value, and this could often actually clearly be done easily, but the developers or engineers responsible (or other members of the surrounding community) are dismissive of such things being problems at all.

Most programmers know that “magic numbers” tend to degrade code quality, but are they aware that hard-coding types (i.e. “magic typing”) often does too?

It is almost ubiquitous knowledge among educated and/or experienced programmers that “magic numbers” (i.e. hard-coding specific numeric values in multiple different locations in code) is generally highly damaging to code quality, readability, and maintainability.

It is a lot harder to change code that uses a lot of magic numbers, because every time you need to change one of those numbers you not only have to remember (or find) all the places where that number is, you have to also make sure that each instance of that number that you do find is actually related to the other ones that you are changing and not merely coincidentally the same. This can quickly become nightmarishly tedious, error prone, time consuming, and inflexible. Thus, it is common to instead use named constants so that it is easy to change all the related number instances at once in a much more foolproof way.

Programming languages should provide at least two separate switch statement keywords, one for fall through and one for no fall through, instead of forcing one or the other.

Programming languages with switch control flow statements typically seem to either (1) make it so that switch statements have fall through behavior (which is often error prone, since it is the less common use case) or else (2) force switch statements to never fall through. Neither of these choices is the wisest choice though.

There is no actual reason why a programming language should be forced into being artificially handicapped by either of these variants’ weaknesses. Instead, the programming language could simply make two different keywords available for switch statements, in such a way as to clearly indicate which behavior will be the result.

The “single return” (aka “only return once”) style that many programmers use is almost always inferior to a “return early, return often” style.

There are many programming conventions and styles that are touted as being “best practices” by some but which are actually based on an incomplete or flawed mental model of how to maximize one’s ability to reason about code as effectively as possible. Following programming style conventions without really understanding them is often quite harmful. Truly good code style requires a basis in logical reasoning, not in mere imitation of what other people arbitrarily say to do.

The popular (but harmful) belief that some programmers have that there “should only be one return statement in each function” is one of the best examples of a “best practice” that is actually nearly always counterproductive rather than helpful. In this case, a “single return” policy would ironically be best described as a “worst practice” instead of as “best practice”, given that this particular style convention is truly one of the most consistently harmful styles to code readability and quality.

Igor’s C++ Grimoire: A hidden gem of C++ reference material that not enough people know about

There are several C++ reference and documentation pages for the C++ programming language and the standard library (std::) and STL that one inevitably ends up coming across during the course of studying C++ and trying to use/learn the built-in features and common extensions of C++ when programming.

Both C and C++ tend to not have the most memorable names for some functions and types and variables etc, and can also have some tricky special cases in terms of code behavior, so the use of reference pages for C++ coding is essentially unavoidable, even more so than usual for programming languages.

Contrary to popular opinion, implementation inheritance is not a conceptually correct representation of an “is a” relationship in programming.

One of the most common intuitions people have in object oriented programming is that inheritance models an “is a” relationship between objects whereas composition models a “has a” relationship between objects. In the case of composition, this intuition is valid and causes no problems. Unfortunately however, the corresponding intuition for inheritance is actually wrong, despite how extremely popular it is.

The problem is that inheritance only actually models a small subset of possible “is a” relationships, and thus when programmers have the habit of thinking “I should use inheritance!” whenever they see any “is a” relationships the inevitable outcome is nearly always a poorly designed representation of the relationships between the objects being modeled.

An expressive system for specifying constraints in code makes reasoning about software much easier.

Hello. Since this website is only a day or two old at this point, there is probably nobody (or almost nobody) reading it so far. However, be that as it may, I want to at least put some form of real content up now, even if it is of little significance, so that I can start to get a bit of momentum going and so that the site will no longer be totally useless. As such, on a whim, I have decided to make this post here (the 2nd post ever) about some of my personal thoughts on the importance of being able to express constraints in an effective way when doing computer programming.

Despite how obvious one might think this point is, I think the point is still worth saying here. I find that it is actually surprisingly common for many popular programming languages and related tools to have unnecessarily weak or arbitrarily limited constraint specification systems. There is also likewise a surprising abundance of programmers who don’t seem to really grasp the usefulness of an expressive constraint system either.