Shortening variable names is a huge waste of time.

if(ts.has(t)) {
    ts.close();
}

TS. Tidy Storage. Tennant Summit. The Store. Team Session. What is ts? What is t?
Looking at the code closer, we discover the following.

TrainStation ts = city.getClosestTs();

Aha, ts is a train station, of course - that makes sense!
Okay. Let's go back to the code again.

if(ts.has(t)) {
    ts.close();
}

Could that mean the t is a train? Probably, but we would have to check to be sure. Perhaps it uses a custom implementation of Train Train t = new ElectricTrain(). However, perhaps they should have used et instead of t.

Advantages shortening variables

Let us look at the advantages of shortened variables.

  1. You save horizontal screen space.

A very disappointing list of one. However, some may claim the following:

  • "You save time spending less time typing!"
  • "You will code faster!"

And to that I say, BALONEY!

Are shortened variables a waste of time?

Believe it or not, shortening variables is a big time waster. Not only are you wasting your own time, you are also wasting everyone else's time.
The reason for this is surprisingly intuitive once you stop to think about it.

Workflow using shortened variable names

This is assuming you are not very familiar with the code. If you are very familiar with the code, you can skip step 2 and 4, since you already have that knowledge somewhere in your memory.

  1. You read the code
  2. You need to find out what ts is.
  3. Keep a mental map that ts is TrainStation
  4. Find out what t is.
  5. Keep a mental map that t is Train
  6. Make changes to code
  7. Always remember that ts is TrainStation, and t is Train.

Workflow using long descriptive names

  1. You read the code
  2. Make changes to code

Not a lot of steps involved when you cut the shortened variables.

Keeping a Mental Map

think

In your mind, perceiving the variable name "hello" is faster than "h".
When you look at "h" you have to recall that "h" means "hello", every single time. When I say recall, I don't mean that you need to stop to figure out that "h" means "hello". You obviously know that, but you still have to form a mental link between "h" and "hello". This takes a little time that gives your mind more work.

Imagine how many times you have to do this. The time you claim to save typing "h" is lost countless times over with the additional time you spend mapping these variables.
You might even say that the act of shortening variables are selfish. Remember you are also wasting the time of everyone else reading the code.

This is not the worst part. It is even more costly when you jump between code context. "h" in our example might represent "heavy" in another class.
The time it takes to absorb a new context with multiple variables that are shortened is more than likely much greater than the time you waste working with only one shortened variable.

In Summary

Shortening variables add several unnecessary and wasteful steps in your mental workflow. Not only is it an inefficient way to code, you are also wasting the time of your entire team.
In contrast, using longer descriptive variable names provides the user with the information then and there, without the need to look it up.

Don't make the developers have to think more than they already do!

Let me finish this off with a relevant quote:

"Indeed, the ratio of time spent reading versus writing is well over 10 to 1. We are constantly reading old code as part of the effort to write new code. ...[Therefore,] making it easy to read makes it easier to write." - Robert C. Martin (Clean Code: A Handbook of Agile Software Craftsmanship)