contrarian – Jesse Bollinger

Arrogance and humility are equally bad. One should view both others and oneself exactly in proportion to reality, without distortion.

This article is about something I’ve been thinking about on and off for years, which I finally decided to write about because the narrative surrounding the issue seems far too philosophically homogeneous.

Anybody who has followed my work has probably realized by now that I like to pose provocative thought experiments that question popular assumptions to see how important concepts and nuances are often overlooked. This will be another instance of that.

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.

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.