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.

We have matured and confirmed spaghetti code is unmaintainable and error prone. Structured Programming solved that problem years ago.

We got rid of the sentence thanks to Edsger Dijkstra’s incredible paper: Go To Statement Considered Harmful.

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.

Photo by Brett Jordan in Pexels

Problems

  • Mutability
  • Incomplete objects
  • Concurrency inconsistencies between creation and essence setting.
  • Setters

Solutions

  • Pass the object’s essence on creation

Examples

  • Some persistence frameworks in static typed languages require an empty constructor.

Exceptions

  • Stateless objects. Always better solution than static class methods.

Sample Code

Wrong

Right

Detection

Any linter can warn this (possible) situation.

Tags

  • Essence
  • Incomplete
  • Mutable

Conclusion

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)…


The code smells bad. Let’s see how to change the aromas.

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.

Code Smells


Your objects are a bunch of public attributes without behavior.

Photo by Stacey Vandergriff on Unsplash

Protocol is empty (with setters/getters).

If we ask a domain expert to describe an entity he/she would hardly tell it is ‘a bunch of attributes’.

Problems

Solutions

1) Find Responsibilities.

2) Protect your attributes.

3) Hide implementations.

4) Delegate

Examples

  • DTOs

Sample Code

Wrong

Right

Detection

Detection can be automated with sophisticated linters ignoring setters and getters and counting real behavior methods.

Also Known as

  • Data Class

Tags

  • Anemic
  • OOP as Data
  • Encapsulation
  • Setters/Getters
  • Mutability

More info

This…


result = ???

Photo by KMA . on Unsplash

TL;DR: Use good names always. Result is always a very bad name.

Problems

  • Readability

Solutions

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.

Sample Code

Wrong

Right

Detection

We must forbid the word result to be a variable name.

Tags

  • Readability

Conclusion

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. …


Exceptions are a great way of separating happy path versus trouble path. But we tend to over-complicate our solutions.

Photo by David Clode on Unsplash

TL;DR: Don’t nest Exceptions. Nobody cares of what you do in the inner blocks.

Problems

  • Readability

Solutions

1. Refactor

Sample Code

Wrong

Right

Detection

We can detect this smell using parsing trees.

Tags

  • Exceptions

Conclusion

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.

Relations

More Info

Credits

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…


If a name is already used, we can always prefix it with ‘the’.

Photo by Josue Michel on Unsplash

TL;DR: don’t prefix your variables.

Problems

  • Readability
  • Meaningless names

Solutions

1. Use intention revealing names.

2. Avoid *Indistinct noise words*.

Sample Code

Wrong

Right

Detection

As with many of our naming conventions, we can instruct our linters to forbid names like *theXxx…*.

Tags

  • Readability

Conclusion

Always use intention revealing names.

If your names collide use local names, extract your methods and avoid ‘the’ prefixes.

Relations

More info

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.


Processing an algorithm as a sequence of nested callbacks is not clever.

TL;DR: Don’t process calls in a callback way. Write a sequence.

Problems

  • Readability
  • Hard to debug.
  • Complexity

Solutions

1. Change callbacks to sequence calls.

2. Extract repeated Code

3. Refactor.

Sample Code

Wrong

Right

Detection

This problem shines at the naked eye. Many linters can detect this complexity and warn us.

Tags

  • Readability
  • Complexity

Conclusion

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.

Relations

There are two ways to write code: write code so simple there are obviously…


Timestamps are widely used. They have a central issuing authority and do not go back, do they?

TL;DR: Don’t use timestamps for sequence. Centralize and lock your issuer.

Problems

  • Bijection Fault.
  • Timestamp Collisions.
  • Timestamp precision.
  • Packet Disorders.

- Bad Accidental Implementation (Timestamp) for an Essential Problem (Sequencing).

Solutions

1. Use a centralizing sequential stamper. (NO, not a Singleton).

2. If you need to model a sequence, model a sequence.

Sample Code

Wrong

Right

Detection

Timestamps are very popular on many languages and are ubiquitous.

We need to use them just to model… timestamps.

Tags

  • Bijection

Conclusion

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…


Don’t make weak tests to create a false sensation of coverage.

TL;DR: Test Assertions should be precise. Not too Vague and not too specific. There is no silver bullet.

Problems

  • False Negatives
  • Lack of Trust

Solutions

1. Check the right case

2. Assert for a functional case.

3. Don’t test implementation.

Sample Code

Wrong

Right

Detection

With Mutation Testing techniques we can find these errors on our tests.

Tags

  • Testing

Conclusion

We should use development techniques like TDD that request concrete business cases and make concrete assertions based on our domain.

Relations

More info

Credits

This smell was inspired by Mario Cervera and used with his permission.

A program that produces incorrect results twice as fast is infinitely slower.

John Osterhout

Maximiliano Contieri

I’m senior software engineer specialized in declarative designs. S.O.L.I.D. and agile methodologies fan.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store