970 reads

How to Find The Stinky Parts of Your Code (Part X)

by Maximiliano ContieriApril 29th, 2021

Too Long; Didn't Read

Part I can be found here, Part I, Part II, Part III, Part IV, Part V, VI, VII, VIII and IX. Part I: Repeated code is always a smell. Diagrams are not code. They are just Diagram Smells. They cannot be a code smell. Part V: Code Without Standards. Caches are sexy. We need to avoid one-night-night Caches. They stand to avoid the sexy ones. Part X: How to Find The Stinky Parts of Your Code (Part X)

Company Mentioned

featured image - How to Find The Stinky Parts of Your Code (Part X)

More code smells. No joke.

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.

This is part V. Part I can be found here, Part II here, Part III is here, Part IV here, part V, VI, VII, VIII and IX.

Let's continue...

Code Smell 46 — Repeated Code

DRY is our mantra. Teachers tell us to remove duplication. We need to go beyond.

Photo by Sid Balachandran on Unsplash

Problems

Code Duplication
Maintainability
Don’t Repeat Yourself

Solutions

Find repeated patterns (not repeated code).
Create an abstraction.
Parametrize abstraction calls.
Use composition and never inheritance.
Unit test new abstraction.

Sample Code

Wrong

Right

Detection

Linters can find repeated code.

There are not very good finding similar patterns.

Maybe soon machine learning will help us find such abstractions automatically.

For now, it is up to us, humans.

Examples

Automatic Code Generators

Conclusion

Repeated code is always a smell.

Copying and pasting code is always a shame.

With our refactoring tools, we need to accept the duplication remove challenge trusting our tests as a safety net.

More info

Don't Repeat Yourself

Copy and paste is a design error.

David Parnas

Code Smell 47 — Diagrams

Diagrams are not code. They cannot be a code smell. They are just Diagram Smells.

Photo by Nick Seagrave on Unsplash

Problems

Maintainability
Trash code
Code Duplication
Diagrams focus only on structure (accidental) and not behavior (essential).

Solutions

Use diagrams only to communicate ideas with other humans.
Program on your favorite IDE.Thrash all diagrams.
Even the ones generated from the source code.
Trust your tests. They are alive and well maintained.
Use Domain Driven Design technique.

Sample Code

Wrong

Right

Detection

We can remove all code annotations and forbid them by policy.

Examples

Automatic Code Generators

Conclusion

Designing is a contact sport. We need to prototype and learn from our running models.

Papers and JPGs don’t run. They live in the utopic world where everything works smoothly.

CASE was a very hot trend back in the 90s. No good system was developed with these tools.

More info

The Diagram is Not the Model. The model is not the diagram. It is an abstraction, a set of concepts and relationships between them.

Eric Evans

Code Smell 48 — Code Without Standards

Working on a solo project is easy. Unless you go back to it after some months. Working with many other developers requires some agreements.

Photo by De Jesus de Blas — Russia

Problems

Maintainability
Readability

Solutions

Automate your styles and indentation.
Enforce agreed policies.

Sample Code

Wrong

Correct sample taken from Sandro Mancuso’s bank kata

Right

The right example has several other smells, but we keep it loyal to its GIT version in order to show only code standardization issues.

Detection

Linters and IDEs should test coding standards before a merge request is approved.

We can add our own naming conventions related to Objects, Classes, Interfaces, Modules etc.

Examples

PSR2

Conclusion

Use coding standards in your projects.

A well-written clean code always follows standards about naming conventions, formatting and code style.

Such standards are helpful because they make things clear and deterministic for the ones who read your code, including yourself.

Code styling should be automatic and mandatory on large organizations to enforce Collective Ownership.

More info

What Exactly Is A Name: The Quest [Part I]

The nice thing about standards is that there are so many to choose from.

Andrew S. Tannenbaum

Code Smell 49 — Caches

Caches are sexy. They are a one-night stand. We need to avoid them in a long-term relationship.

Photo by Aimee Vogelsang on Unsplash

Problems

Coupling
Testability
Cache invalidation.
Maintainability
Premature Optimization
Erratic Behavior
Lack of transparency
Non-Deterministic behavior

Solutions

If you have a conclusive benchmark and are willing to pay for some coupling: Put an object in the middle.
Unit test all your invalidation scenarios. Experience shows we face them in an incremental way.
Look for a real world cache metaphor and model it.

Sample Code

Wrong

Right

Detection

This is a design smell.

It will be difficult to enforce by policy.

Conclusion

Caches should be functional and intelligent.

In this way we can manage invalidation.

General purpose caches are suitable only for low level objects like operating systems, files and streams.

We shouldn’t cache domain objects.

This page is hosted on a cached website.

More Info

There are only two hard things in Computer Science: cache invalidation and naming things.

Phil Karlton

Code Smell 50 — Object Keys

Primary keys, IDs, references. The first attribute we add to our objects. They don’t exist in the real world.

Photo by Maurice Williams on Unsplash

Problems

Coupling
Accidental Implementation
Bijection Principle Violation.

Solutions

Reference object to objects.
Build a MAPPER.
Only use keys if you need to provide an external (accidental) reference. Databases, APIs, Serializations.
Use dark keys or GUIDs when possible.
If you are afraid of getting a big relation graph use proxies or lazy loading.
Don’t use DTOs.