There are a few reasons that Best Practices get specified in a profession. Provide standards for judging proposed solutions. Provide cover for unforeseen circumstances. Provide a starting point for discussions to improve the state of the art even more. Help more junior people make better decisions before they fully understand the field. Applied to software,… Read More »
This is yet another in the Best Practices Gone Bad series of posts. Around two decades ago, the book Design Patterns (often called the Gang of Four, or GoF, book) was published. This book introduced a large number of programmers to a new approach to thinking about solutions. For those who are not familiar with… Read More »
As a first post in the Best Practices Gone Bad series, I figured I would take an simple example from a previous job. An Example In that position, there were two best practices that intersected to generate unreadable code. The first practice was expressive names. All names of variables, classes, and methods were required to… Read More »
Most professional fields develop a set of best practices that help people in the field produce consistent solutions to similar problems. Any given problem has an infinite number of potential solutions, some of those will actually work. Fewer still will work well. Best practices tend to prune some of the bad solutions by pointing out… Read More »
Many programs have a need to store program state to disk at various points. An approach used by many of these programs is to serialize the objects representing the program state directly to disk (or a database). Back in 2004 (XML-Serialized Objects and Coupling), I described a coupling problem caused by automatically serializing objects to… Read More »
There is a technique I have seen used many times in my career called Lazy Initialization. The purpose of this technique is to delay an expensive initialization (or object construction, or calculation) until you actually need it. Just like any technique, Lazy Initialization has both advantages and disadvantages. The advantages are a pretty obvious: If… Read More »
Continuing the line of thought from last time (Sharp Tools vs. Frameworks), another issue I see in quite a few frameworks and some systems is a code anti-pattern I’ll call The Modular Monolith. We all know that modularity is a good thing to have in a system. Modular code, in general, reduces coupling between components,… Read More »