How long is too long for a variable name?

I suppose, I'm looking for both answers that are both technical and opinionated in nature.

How long is too long for a variable name?

I always try to make my variables as short as they can be while maintaining the proper level of meaning. However, as some "sub-routines" increase in complexity, I'm finding the need to create longer variable names to continue to have them be meaningful. Does the length of a variable have an impact on performance?

For instance, I just used MBReadPerSecondAverageAfterLastFlushToLog, which is as close to supercalifragilisticexpialid开发者_开发技巧ocious as I hope I ever come.

Thanks,

Matt

p.s. Sorry if you now have a Mary Poppins song in your head.

---

You are correct in naming variables as short as you can while retaining enough meaning to be able to describe what the variable does by just looking at its name.

No, the length of a variable name has absolutely nothing to do with performance.

Edit:

For some reason I thought you were talking about C++. If you are (or C or Delphi or another compiled language) the above is correct (barring debug information which won't appear in a release executable).

For dynamic languages such as Lua or Python or Ruby, the length of a variable name could very well affect runtime performance depending on how variable name lookups are performed. If variable names are hashed and then the hash is used to index a table of values to get the value of the variable, then natrually the more data the hash function has to process, the longer it will take.

That said, do not sacrifice meaningful variable names for short ones just because you think they'll be faster. The speed increase will usually be extremely negligible, and definitely not worth sacrificing the maintainability of your program for.

---

Make it as long as it takes to make it clear. But, in your example, it looks like you may have some other issues.

1. The name of the Variable indicates to me that you have a function that has more than one responsiblity.

2. Isn't this what objects are for? Imagine an object called Reads, this is just a really simple example, that may/may not in anyway match what you need.

     Reads.AveragePerSecond  
     Reads.Size  
     Reads.IsLoggedFlushed
   

---

I think the main problem here that you forgot that variables are not some sort of global unique identifiers. They have a context, which helps explaining them. By reading them you normally know that context: namespace, class name, method name, the meaning of the previous lines, method name by giving value to the variable or in your example some basic scientific knowledge like MBps is a unit of data transfer speed, speed is always measured by average, etc... The MBReadPerSecondAverageAfterLastFlushToLog can easily be just Speed if the context explains the rest...

To make it easier to understand if you want a beer than you just say to your girlfrend that Give me a beer please! not that Give me an 5°C Gösser beer from the fridge I bought yesterday in the shop for 1$ please!

What kind of overhead does introducing an object do? Is not declaring a variable much less?

This might be premature optimization. First you write the code, after that should you look for bottlenecks...

I already have a "ReadFiles" method where this like MBReadPerSecondAfterFlushToLog, KBReadPerSecondAverageAfterLastFlushToLog, MBReadPerSecondAveragePerReadOperation, etc etc etc are located.

These might be ReadSpeadAfterFlushToLog if the first 2 variables are about the same thing and you should have a DataTransferSpeed class, which does the unit conversion for you when needed. The third variable can be AverageSpeedPerReadOperation. If we have only reading speeds here and the context describes it, e.g. the method name contains that info, then even the Read part can be omitted. If you have way too many variables, then you might need multiple smaller methods and you might want to group the variables you use with structs and objects.