Why the first instruction we learn to program should be the last to use.
Nobody uses GOTO instruction anymore and few programming languages still support it.
Next evolution step will be removing most IF statements
IFs/Cases and Switches are GOTOs disguised as structured flow.
Our tool will be Object Oriented Programming principles.
Incomplete objects cause lots of issues.
Any linter can warn this (possible) situation.
Always create complete objects. Make their essence immutable to endure through time. Every object needs its essence to be a valid one since inception.
Writing a class without its contract would be similar to producing an engineering component (electrical circuit, VLSI (Very Large Scale Integration)…
In this serie we will see several symptoms and situations that make us doubt the quality of our developments.
We will present possible solutions.
Most of these smells are just clues of something that might be wrong. They are not rigid rules.
If we ask a domain expert to describe an entity he/she would hardly tell it is ‘a bunch of attributes’.
1) Find Responsibilities.
2) Protect your attributes.
3) Hide implementations.
Detection can be automated with sophisticated linters ignoring setters and getters and counting real behavior methods.
TL;DR: Use good names always. Result is always a very bad name.
1. Rename result.
2. If you don’t know how to name it, just name the variable with the same name as the last function call.
3. Don’t use IDEs without automatic refactors.
We must forbid the word result to be a variable name.
Result is an example of generic and meaningless names.
Refactoring is cheap and safe.
Always leave the campground cleaner than you found it.
When you find a mess on the ground, clean it, doesn’t matter who did it. …
TL;DR: Don’t nest Exceptions. Nobody cares of what you do in the inner blocks.
We can detect this smell using parsing trees.
Don’t abuse exceptions, don’t create Exception classes no one will ever catch, and don’t be prepared for every case (unless you have a good real scenario with a covering test).
Happy path should always be more important than exception cases.
Thanks to @[Rodrigo](@rodrigomd) for his inspiration
Writing software as if we are the only person that ever has to comprehend it is one of the biggest mistakes and false assumptions that…
TL;DR: don’t prefix your variables.
1. Use intention revealing names.
2. Avoid *Indistinct noise words*.
As with many of our naming conventions, we can instruct our linters to forbid names like *theXxx…*.
Always use intention revealing names.
If your names collide use local names, extract your methods and avoid ‘the’ prefixes.
One difference between a smart programmer and a professional programmer is that the professional understands that clarity is king. Professionals use their powers for good and write code that others can understand.
Robert C. Martin
This article is part of the CodeSmell Series.
TL;DR: Don’t process calls in a callback way. Write a sequence.
1. Change callbacks to sequence calls.
2. Extract repeated Code
This problem shines at the naked eye. Many linters can detect this complexity and warn us.
Callback Hell is a very common problem in programming languages with futures or promises.
Callbacks are added in an incremental way. There’s no much mess at the beginning.
Complexity without refactoring makes them hard to read and debug.
There are two ways to write code: write code so simple there are obviously…
TL;DR: Don’t use timestamps for sequence. Centralize and lock your issuer.
- Bad Accidental Implementation (Timestamp) for an Essential Problem (Sequencing).
1. Use a centralizing sequential stamper. (NO, not a Singleton).
2. If you need to model a sequence, model a sequence.
Timestamps are very popular on many languages and are ubiquitous.
We need to use them just to model… timestamps.
This smell was inspired by recent Ingenuity software fault.
If we don’t follow our MAPPER rules and model sequences with time, we will face trouble.
Luckily, Ingenuity is…
TL;DR: Test Assertions should be precise. Not too Vague and not too specific. There is no silver bullet.
1. Check the right case
2. Assert for a functional case.
3. Don’t test implementation.
With Mutation Testing techniques we can find these errors on our tests.
We should use development techniques like TDD that request concrete business cases and make concrete assertions based on our domain.
This smell was inspired by Mario Cervera and used with his permission.
A program that produces incorrect results twice as fast is infinitely slower.
I’m senior software engineer specialized in declarative designs. S.O.L.I.D. and agile methodologies fan.