STUPID Principles
Now that you have learned about the SOLID principles, you can start coding like a master who never writes bad code (“code smells”), and everything is right with the world!
Well, not quite. You’re human. And as a human, you are prone to making mistakes and not even be aware of it. Yes, we all will write bad code (including yours truly), but that’s OK as long as you are aware of it.
So, how do I become aware that I am coding down the wrong path?
It comes down to reviewing what you have written.
You have written code that works, but could it be better? Take a step back, look at what you’ve written, and see if your code fits any of the STUPID principles.
In essence, the STUPID principles come into play when you don’t follow the SOLID principles. To be more precise, STUPID stands for the following:
Singleton
Tight coupling
Untestability
Premature optimization
Indescriptive naming
Duplication
Let’s go through each one and describe the issues with each.
Singleton
In C#, singletons are created when you use the static keyword in your classes, methods, and properties.
It is a very well-known design pattern called the singleton pattern. In Part 3, we’ll dive deeper into this pattern.
If this is a design pattern, why is it included with the STUPID principles?
Singletons are effortless to use, and therefore easy to overuse. You’ll soon notice you have them everywhere, which is not a good idea, especially since they are considered an anti-pattern.
What’s an anti-pattern?
An anti-pattern is a process or pattern that initially looks to be appropriate, but results in more bad consequences than good. Also, there exists a better solution that is proven to be more effective.
There’s nothing wrong with using singletons sparingly, but they appear as a symptom to a problem. One reason is that singletons are in a global state and difficult to test. Also, programs that rely on global state hide their dependencies.
Should I always avoid them?
That’s a controversial issue, and if you talk to developers, you’ll get different opinions.
Try to avoid the static items that can lead to tight coupling.
Tight Coupling
I mentioned tight coupling in our discussion of the dependency inversion principle:
The goal is to not have a tightly-coupled system where every module is directly referencing lower-level modules. Thus, why we need to abstract that out to get to a more loosely-coupled system.
Again, if you modify one module in your application, and it requires you to modify another module, you then have coupling, which is hard to use and test.
Untestability
You may have noticed that I mentioned that both the singleton and tight coupling principles are hard to test. That’s a problem because you need to make your code testable.
The most effective way of testing your code is by writing unit and integration tests.
Premature Optimization
Simply put, premature optimization is spending a lot of time on something that you may not need. Donald Knuth mentions in his book, The Art of Computer Programming:
The real problem is that programmers have spent far too much time worrying about efficiency in the wrong places and at the wrong times; premature optimization is the root of all evil (or at least most of it) in programming.
An example of this is a company spending way too much time on figuring out how to scale their application to millions of users. Granted, this is a valid concern, but not necessarily one on which you should act. Before worrying about handling millions of users, a company should be more concerned that people will use the application.
Getting customer feedback is a priority!
Indescriptive Naming
Make your code readable! Don’t use abbreviations and naming patterns that only you can understand. Use good descriptive naming for classes, variables, attributes, and methods. Other developers will be reading your code. Make it understandable and readable.
As Uncle Bob puts it in his video lecture series, “Your code should read like prose."
Duplication
If you find yourself clicking Ctrl+C followed by Ctrl+V in your application, STOP! You just duplicated your code in another section of your application.
Follow these two simple principles:
Don’t repeat yourself (DRY): Every piece of knowledge or logic must have a single, unambiguous representation within a system.
Keep it simple, stupid (KISS): Most applications work best if they are kept simple, rather than complicated. The design goal is simplicity.
Let’s Recap!
The STUPID principles represent "code smells," or bad code:
Singletons are an anti-pattern where it initially looks to be appropriate but results in more bad consequences than good. Also, there exists a better solution that is proven to be more effective.
Tight coupling is having modules dependent on other modules.
Untestability is where you can’t test a module that is evident of tight coupling.
Premature optimization is when you spend too much time worrying about what you think you need over what is truly necessary.
Indescriptive naming is when you don’t use good explanations for your classes, methods, attributes, and variables. Don’t be cryptic! Make your code read like prose.
Duplication is when you use duplicate code in your system. Follow these principles: don’t repeat yourself (DRY) and keep it simple, stupid (KISS).
In other words, you’re following the STUPID principles if you’re not following SOLID.
You’ve got the guiding principles down, so take a quick quiz to check your understanding, and I’ll see you in Part 3, where we’ll expand your quality coding tool belt with design patterns!
