Code Smell 33 - Abbreviations

Subscribe to my newsletter and never miss my upcoming articles

Abbreviating is very important so that we look smart and save memory and mind space.


  • Coupling

  • Bad Naming

  • Declarativeness

  • Ambiguity

  • Readability

  • Premature Optimization


  1. Use meaningful/declarative names.


  • Variable naming

  • Function naming

  • Package naming

  • Class Naming

Sample Code



We can't automate choosing what is a short name and a declarative.

Some "modern" and shinny languages enforce this bad practice. So we should wisely choose a good language instead.


  • Declarative


Computer science was born from the mother of science (mathematics). In math, the assignment of single letter variables (i, j, x, y) is a good practice.

The concept of reference arose from the variable.

Many people wondered why mathematicians can work with such short variables, and computer scientists cannot.

For mathematicians, once entered into a formula, variables lose all semantics and become indistinguishable.

We need to care more about semantics and reading.

Our brain wastes a lot of energy figuring out what is the meaning of an abbreviation.

Sometimes we even mistake them

/usr stands for universal system resources not user

/dev stands for device not development.

It is 2020, We need to write software for humans, not for compilers.


More info


Photo by Jessica Knowlden on Unsplash

A long descriptive name is better than a short enigmatic name. A long descriptive name is better than a long descriptive comment.

Robert Martin

This article is part of the CodeSmell Series.

Tapas Adhikary's photo

Maxi Contieri,

Maxi, Someone told me a while back, name your variables with the same care as you would do it for your kids! It was a heavy but useful warning 😃!

Loved your series so far!

Maxi Contieri's photo

Awesome advice

PS: My kids aren't named "Jn" and "pt".

Rodion Borisov's photo

Hm... It twists my mind when I cannot find package called "formatter", and everyone referring to sources or documentation will be confused about import "formatter" even being possible in Go, because in this case formatter is an alias for fmt 🤷‍♂️

Better example of inapproptiate usage would be: abbreviations that persist without definition in glossary and too many abbreviations.

Show +2 replies
Maxi Contieri's photo

Rodion Borisov

We read both when understanding code. Of course, we read more 'variables' than 'packages'

And I'm certain:

Standard Library > Good names

What can we have the best of both worlds?

Why a "modern" language have the same problems as a 50s one?

Languages force culture. So a legion of Go developers will write lousy names, and we will need to maintain that ugly code.

Code is read 10 times for every 1 write and modern compilers are not biased by length and don't need to save space.

50s problems on modern languages.

Rodion Borisov's photo

Maxi Contieri thanks for detailed proposal! This topic really should bring up how bad abbreviations are born in programming culture and how they affect the technical debt ☝️👍

Edidiong Asikpo's photo

This series is very amazing. I can't wait to see the next code smell list.

You also write consistently as well. Do you mind sharing some tips with me? 😉

Maxi Contieri's photo

Thank you, @Edidiong Asikpo](@didicodes)!

I started this series as a twitter thread, so I'm writing back several people's experiences.

I create new drafts when I'm writing articles to keep focus on the main one. Then I publish them when I think they are mature enough.

Seems obvious, but to have the habit you need to fake it for some time.

Here are more advices!

Hope this helps

Edidiong Asikpo's photo

This makes a lot of sense Maxi. Thanks for the information.

I'll read through the article you shared and let you know if I have any other questions 💛