Quality Code: Patterns
Quality Code: Patterns
Humans are quite good at spotting patterns. We often find patterns where there are none (see gambler's fallacy, apophenia, etc.)! The point being, patterns are a very helpful way for someone to understand things. In our case, these things are code.
Shared Patterns as Code
Continuing our previous thoughts on seeing code as a shared resource, it is helpful (to us at least) to view our share resources in patterns. I've been really wanting to talk about this because I see it as a major insight on my path to having a better understanding software and the projects that create, maintain, and modify software. When I started out, code was merely the commands written down in a specific to achieve a particular goal. There was no notion of maintainability, nor was it intended to be worked on by other individuals.
Individual Style, yet Structured
Individuals develop their style over time. An important side-note is that coding is not a rigid, yet magical process by which software is created. Creation requires creativity, and creating code is no exception. I do not consider myself an exceptional developer, but I have come a long way since when I put together my very first program (a Java applet that tracked players' beer pong statistics during a game. It is a hideous mess - I still have it.) Having a style when coding isn't a bad thing. The thing is, there is often no convention - it's like writing an essay with no paragraphs. Higher level concepts like Paragraphs give rise to patterns. An example of such a pattern is "Abstract, Introduction, Body, Conclusion." When coding, I use a couple of personal patterns that I find help me understand what I was trying to accomplish 8 months ago.
Practicality of Code Patterns
Patterns are easy to implement and highly practical! Since they actually reduce the cognitive overhead required to understand code, it ends up being a pretty big win. Also, there is no such thing as the "wrong" pattern, as long as you use any pattern in more than one place you will gain the benefit! Think of it like style conventions, but for logical groups of lines of code.
Examples of Patterns
We have a couple basic ways we group code, or structure our functions. In addition to the pattern being fairly obvious when inspecting the code, we include a quick comment to indicate the intended pattern. To borrow from existing terms, we call one pattern Base Case Pattern. This means we have some early conditional to catch a specific situation, otherwise the function operates normally. On the other end, is the Fall Through Pattern. This is usually if there is more than one situation we need to watch out for, with a final, default value being returned. By simple virtue of using patterns, we add a layer of expressiveness that only serves to increase our codes flexibility, maintainability, and overall quality.
Patterns as a Signal of Quality
Patterns have been a huge win for our projects and our internal tools. It is one of our main pieces to the puzzle of Quality Code. They are very simple to implement, and highly effective. I only wish someone told me about them earlier! Furthermore, the nature of our projects are long-term, so having faster/high quality turnarounds on updates, upgrades, and releases makes us more profitable. At the end of the day, that's why we're here.
Tap or click on these posts to navigate to the next or previous posts.
This post is part of a larger series. Tap or click on a post to view more in this series.
