I’m senior software engineer specialized in declarative designs and S.O.L.I.D. and Agile lover.
Are we done on code smells? Guess not.
We see several symptoms and situations that make us doubt the quality of our development.
Let’s look at some possible solutions.
Most of these smells are just hints of something that might be wrong. They are not rigid rules.
Small changes yield unexpected problems.
- Cover with tests.
- Refactor and isolate what is changing.
- Depend on interfaces.
- Legacy Systems
There are multiple strategies to deal with Legacy and coupled systems. We should deal with this problem before it explodes under our eyes.
Architecture is the tension between coupling and cohesion.
Discouraged by Object-Oriented Programmings, Many mixed languages support it. And developers abuse them.
- Wrap the function in a context object.
- External Resources Access, Database access, Time and Operating System resources.
Many modern languages avoid them. For the permissive ones, scope rules can be applied and automatically checked.
Structured programming considers global functions harmful. Yet, we can observe some bad practices cross paradigm boundaries.
Singleton and Classes are global points of access.
The road to programming hell is paved with global variables.
Yet another global access coupled with laziness.
- Protocol Overloading
- Class Single Responsibility Principle is to create instance. Honor it.
- Delegate method to instance.
- Create stateless objects. Don’t call them helpers.
- Static class methods
- Static attributes
We can enforce a policy to avoid static methods (all class methods but constructors).
Class are globals disguised. Polluting their protocol with “library methods” breaks cohesion and generates coupling. We should extract static with refactorings.
There is no programming problem that can’t be solved with one more level of indirection.
Disguised as a friendly shortcut is another coupling smell.
- Unexpected results
- Side effects
- Ripple Effect
- In languages with optional arguments but limited to basic types, we need to set a flag and add an accidental IF (another smell).
- Make arguments explicit.
- All function calls must have same arity.
- Use Named Parameters if your language supports them.
Detection is easy if language supports optional arguments.
Be explicit. Favor readability over shorter (and more coupled) function call.
The trouble with programmers is that you can never tell what a programmer is doing until it’s too late.
Planning ahead of time needs a crystal ball no developer has.
- Create great models and bijections first.
- Create a conclusive benchmark once the model is working.
- Design for Performance.
- Use Test Driven Development technique. It always favors the simplest solution.
- Weird data structures
This is a design smell so it can not be detected by mechanical tools (yet).
- Premature Optimization
Defer performance decisions until functional models are mature enough.
Donald Knuth created/compiled the best/fastest algorithms and data structures. With great wisdom he warned us of abuse. Why do we think we are smarter than him?
Programmers waste enormous amounts of time worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered.
Premature optimization is the root of all evil.
And that’s it for now.
But rest assured, more smells will come.
Create your free account to unlock your custom reading experience.