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.
Today I wrote a tweet asking for recommendations for junior developers
I got a lot of very interesting answers. I will group them down here.
Tweets are textual, I chose the more representative, corrected some typos and abbreviations and added some references.
I’m not a Jr Dev, yet. But if I had the experience, my advice to a Jr. Dev and to my future self is; be a student for the rest of your career. Listen to every dev no matter the age and experience. Stay humble, that will make people relied on you and reliable means stable job.
We can search all the code for bad named flags.
Flags are widespread on production code. We should restrict their usage and use clear and intention revealing names.
If you lie to the compiler, it will get its revenge.
This article is part of the CodeSmell Series.
We can use almost any linter to find references to classes. We should not abuse since many uses might be false positives.
Dependencies to Interfaces make a system less coupled and thus more extensible and testable.
Interfaces change less often than concrete implementations.
Some objects implement many interfaces, declaring which part depends on which interface makes the coupling more granular and the object more cohesive.
When your code depends on an interface, that dependency is usually very minor and unobtrusive…
We can use almost any linter or create dependency rules searching for bad class references.
We should restrict our classes to small domains and expose just facades to the outside. This greatly reduces coupling.
Write shy code — modules that don’t reveal anything unnecessary to other modules and that don’t rely on other modules’ implementations.
Todos los tutoriales que he leído durante los últimos 30 años comienzan con el infame ejemplo de “Hola mundo”. Esta podría ser una de las razones por las que escribimos software de mala calidad.
We can instruct our static linters to find wrapping methods if they follow conventions like doXXX(), basicXX() etc.
We came across this kind of methods some time in our developer life, We smelled something was not OK with them. Now is the time to change them!
The primary disadvantage of Wrap Method is that it can lead to poor names. …
I’m senior software engineer specialized in declarative designs. S.O.L.I.D. and agile methodologies fan.