The SPOT, or Single Point of Truth, principle is a better and more semantically-focused interpretation of DRY (Don't Repeat Yourself). The principle suggests that for any given piece of information, there should only be one authoritative location where that data is defined or set. For instance, if there's a rule that pizzas need at least one topping, there should be a single place in the code where that condition is articulated. By maintaining a single source of truth, it ensures that when changes need to be made, they aren't sporadically made in one place but not the others.
A related concept to SPOT is code locality. Code locality refers to the organization of related code segments, with the goal of enabling humans to discover and remember related code easily. The idea is to keep related elements as close together as possible in the code, especially when multiple sources of truth are necessary. This organization strategy aids in code comprehension and enhances the efficiency of tracking and implementing changes in the codebase.
The saying, "if things tend to change together, they should be closer together," also aligns with the principle of code locality. Structuring the code in a way that elements likely to change simultaneously are placed together can significantly improve code maintainability. This approach, in contrast to using layers as a primary organizational method, prevents scattering related elements across different top-level directories.
Another aspect of good coding practice that ties in with the SPOT principle is the preference for simpler structures. When structuring the codebase, linear arrangements, or 'lists,' are often more favorable than tree or graph structures. They are easier to understand, and they help prevent unnecessarily complex and convoluted code that could lead to difficulties in maintenance and comprehension.
I'm building a game about software development, incorporating real principles that have proven their usefulness throughout my 20+ years of career experience.
I'm looking for feedback from Alpha version - try game now.
The principle of least power could be seen as an overarching guideline to the practices described above. This principle suggests that the simplest solution capable of effectively solving a problem is usually the best choice. As applied to code structures, while the graph data structure is highly versatile, it should only be used when simpler data structures fall short, minimizing complexity.
While flat data are simpler to handle than tree data, the real distinction comes when processing the data. The reason for this is that trees invite recursion, and as the complexity of the logic increases, it can be increasingly difficult to understand what's going on. Conversely, processing lists iteratively can be less complex, and refactoring recursive code to iterative code can often reveal or solve hidden bugs.
As a junior developer, understanding the balance between too much and too little abstraction is key. While the SPOT principle and related concepts can greatly aid in creating maintainable, efficient code, it's essential to know when to apply these principles. Overcomplicating a simple problem with unnecessary abstractions or prematurely refactoring can be as detrimental as not applying the principles at all. Ultimately, the goal is to write code that effectively addresses the core problem, while also being easy to maintain and understand.
Follow me on X(ex-Twitter)