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…


This handy operator is a troublemaker.

Photo by Greg Rakozy on Unsplash

TL;DR: Don’t mix booleans with non-booleans.

Problems

  • Not Declarative Code
  • Hard to debug
  • Magic Castings
  • Accidental Complexity

Solutions

  1. Be Explicit
  2. Don’t mix Booleans with non-booleans.
  3. Fail Fast
  4. Be Smarter than your compiler.
  5. Stay loyal to the bijection.

Sample Code

Wrong

Right

Detection

Since this is a “feature” in some languages it would be hard to test. We can set programming policies or choose more strict languages.

We should detect ! !! usages in non-boolean objects and warn our programmers.

Tags

  • Casting
  • Coercion
  • Javascript

Conclusion

Languages like JavaScript divide their whole universe into true or false values. This decision hides errors when dealing with non booleans.

We should be very strict and keep booleans…


Getting things is widespread and safe. But it is a very bad practice.

Photo by Vidar Nordli-Mathisen on Unsplash

Problems

  • Naming
  • Information Hiding
  • Coupling
  • Encapsulation Violation
  • Mutability
  • Anemic Models

Solutions

  1. Avoid Getters
  2. Use domain names instead
  3. Protect your implementation decisions.

Sample Code

Wrong

Right

Detection

Getters coincide in certain scenarios with a true responsibility. It will be reasonable for a window to return its color, and it may accidentally store it as color. So a color() method returning the attribute color might be a good solution.

getColor() breaks bijection since it is implementative and has no real counterpart on our mappers.

Most linters can warn us if they detect anemic models with getters and setters.

Tags

  • Information Hiding

Conclusion

Getters and Setters are a poorly established…


This is part of productivity series. You can read previous tips here and here.

1- Lazy people automate 🤖

Try to avoid repetitive tasks.

Use scripts, programming, RPA, or anything suitable for you.

But never automate until you master the tasks.

This is procrastination monkey disguised! 🙈

2- Schedule time on own calendar after setting goals 📆

Put auto meetings to timebox your tasks.

This is especially important if your calendar is public and other people can book you meetings.

3- Schedule 50 minutes or 25 minutes meetings ⏱️

This way you can rest between meetings.

4- Don’t be a slave to your calendar 📅☝️

Plan but don’t over plan or micromanage yourself.

The calendar is at your service. Not the way around.

5- Keep the information in a central place📑

Don’t have multiple ToDos, lists, Trellos, Kanbans, bookmarks.

Use a single one. The way Marie Kondo manages her mess.

6- Sprint and pause like cycling 🚴

Sometimes you need to run…


Let’s break Demeter’s Law.

Photo by Dan Counsell on Unsplash

Problems

  • Unnecessary Indirection
  • Empty Classes
  • Readability

Solutions

1. Remove Middle man.

Sample Code

Wrong

Right

Detection

Same as its opposite smell, We can detect this small using parsing trees.

Tags

  • Coupling
  • Declarative
  • Readability

Conclusion

This is exactly the opposite to Message Chain. We make explicit the message chain.

Relations

More info

https://wiki.c2.com/?MiddleMan

Whenever I have to think to understand what the code is doing, I ask myself if I can refactor the code to make that understanding more immediately apparent.

Martin Fowler

This article is part of the CodeSmell Series.


Nice article and nice explanation of TDD

But it has a severe misconception since the title

TDD has nothing to do with testing.

TDD is about developing. It is a software developing technique.

Testing is another activity

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