My 5 reasons not to use short variable names anymore

Every other day I stumble upon lines like that reviewing code:

sysMgrH = vFgrMan

or

parse1(l, e, arr);
parse2(l2, e2, arr);

Please don’t do that anymore! Choose long and clear variable names, nothing else! Why?

  1. It’s actually allowed to have variable names longer than 1, even longer than 10 characters, if you need that.
  2. Your job is not about saving a couple of keyboard hits or 30 seconds of time, it’s about producing something of high quality. And something maintainable. And sustainable.
  3. Actually writing out the code is only 1% of your time compared to the rest, like e.g. thinking about what you should write. You can as well spend a few seconds more on the writing part.
  4. If you worry about having to write the same 12-characters variable name over and over again: make friends with Ctrl+Space.
  5. But the actual reason, my personal #1 reason, is the following: you don’t write that piece of code for yourself and for right now. It will be existing for the next 5 or 10 years and if you’re lucky dozens of developers will see it. And some of them have to understand it. In 2 months, in a year, in 5 years. But for them it’s not a matter of 30 seconds (that’s the time you saved 5 years ago, remember?), for them it can easily become a matter of hours. Keep in mind that on average more than 50% of software development costs are spent after the initial version is finished.

So here is my appeal: be nice and write your code as if you’d write a novel. Choose nice words, choose long words, and format everything nicely. Think of your fellow developer in the future who will thank you for that.

    Also, be aware of The world’s two worst variable names by Andy Lester.




    • Eric Giese

      You have a point, but that mostly yields for field names, in my opinion.
      In general, have gotten lazy over the years and now i am using (in java) only the camel cases for short lived variable, so FileInputStream is fis.

      Why? Because that object won’t live for more than 2 lines.

      The general rule should be like this:

      Short-living / small scope:
      3- identifier is enough, if the code is written well enough to be self-explanatory. Otherwise, add comments.

      Long-living field / huge method:
      Needs a full qualified name. However, writing methods with more than 30 lines is a vast crime by itself. Rather than introducing long variables, I tend to refactor these beasts into smaller, well defined methods with meaninful names.

      Good functional-oriented and reusable design is usually preferably well documented, but long and quirky imperative code. Even in languages like Java.

    • Bogdan Marian

      Very well said!
      I totally agree with these points.

    • Hendrik Beck

      Thanks for your comments!

      @Eric: Yeah, sure we should distinguish between cases and I’d buy the general rule you suggested right away. But then again, if I’m trying to advocate a change in style then I find it easier to advocate a complete change and to be more strict, even about short-living variables. We know that it won’t be respected 100% of the time anyways.

      I’m also a big fan of re-factoring big methods into smaller ones although not only for code style and readability nor for maintainability or re-usability, but for testability reasons. Just so much easier to write some quick JUnit tests for separate methods.

    • mario

      I’ll try to remind myself of this. However, it’s not appropriate in ALL cases and languages. Especially for Python and list comprehensions it doesn’t make sense to use lengthy names for very temporary data holders [r.title for r in self.fetchThingys()].

    • Pingback: Twitted by viirya()

    • kebomix

      totally agree , great post :-)

    • Till

      Guys, don’t forget last point! Yes there may be exceptions for rules when a variable does not live longer than two lines and so on … But I totally agree with that last point: “… you don’t write that piece of code for yourself and for right now. …” Whether you code in a nice modern language or an obsolete old language like Basic. You should always keep that last rule in mind. Have the discipline to write clean code!

    • Even though using legible and self explanatory variable names makes for semantic and easy to read and decipher code, it can lead to longer processing times on servers for scripting like PHP, ASP, or Python (there’s prob more, those are just examples).

      When it comes to processing large amounts of sql queries or data in general, I’ve found short at the most 3 char length variables work well. And watching memory stats on my hosting server when processing pages, reusing variable names helps to keep memory overhead low. For e.g. I might use $s to do a sql query, and then use $r on the fetch array loop, then if other parts in the same page/script need to make fetch array and sql query calls, i’ll use $s and $r again.

      On a slightly different note. I’ve noticed by watching cpu load times and memory overhead on a local machine when referencing array especially, if you use for e.g. $r[name] as a reference in the array to work with that data, is slower than using $r[4] to reference the same data, obviously 4 would be the 4th position where name coincides within the array.

      I originally started using short var names to save document space and to keep file size down, just as removing all white space does, and studying the speed difference, the change can be quite dramatic, for not only speed, but file size. Just think, if you have your code tabulated, and spaced out, which is great for readability, but not for overall performance.

    • Bubba

      I never cared about people maintaining my code in the future, until I realized that I forget a lot, and I’m one of the people that need the clarity to maintain my own code in the future.

    • stevej

      Long names can make it harder to discern the author’s intention by (over)emphasizing the data locations instead of what the code _does_.

      The problem is worsened when programmers invent lousy names for things as we often do. The bloated source that results can look more like bad prose than an algorithm. [Consider that the same person who wrote the unhelpful comments --if they did-- probably picked the names too.]

      This can be ameliorated, as others here have pointed out, by using short names for short-lived, locally-scoped variables. Readability can be further improved through judicious use of “negative space,” that is whitespace and anonymous functions and/or objects. In other words, pitch the names altogether. As example, FP-style encourages this.

      A style guideline that helps is to require devs to write short and simple classes and functions. This embodiment of the “Single Responsibility Principle” (SRP) produces decent names in my experience. Code review enforcement will help too.