Live data from Hacker News

Is there an excuse for short variable names?

programmers.stackexchange.com

21–30 of 38 posts

Re: Is there an excuse for short variable names?

#21
post #8

Simple solution: in a program source, create a very clear comment header that won't be missed, that explains the meanings of the variables. Also, even though physicists can use any names or lengths they like in their papers, they seem to prefer concision: f = G M1 M2 / r^2 If the reader understands the math, short variable names aid comprehension, not the reverse.

This actually bothered the hell out of me. For anything more complicated that highschool physics, this is terrible. You start to run out of letters and start using capitals and noncapitals, and even worse is that there are some "globals" that are not really variables but well-known constants. So you're trying to distinguish between uppercase / lowercase / variable / constant and keep all that in your head. There real…

> You start to run out of letters and start using capitals and noncapitals, and even worse is that there are some "globals" that are not really variables but well-known constants.

Fair enough, but don't forget the Greek alphabet, both upper and lowercase. There are plenty of math notation issues, but a shortage of symbols isn't on the list. I don't think anyone in physics thinks multiple-character variables solves any real problems. Practitioners are more likely to craft a new symbol, like h-bar (ℏ) for the reduced Planck's Constant, at the point where ordinary h wasn't adequate:

ℏ = h / 2 π

> There really is no logical reason to do this, other than established practice.

I can think of one logical reason -- it works for people who don't think very much about the symbols because they're thinking about the math.

> Don't even get me started on the mathematician way of explaining things, where instead of explaining the concept and filling in the gaps, you take a 20 variable equation and start by describing all the variables one by one.

I won't try to excuse every example of this, but in physics, explaining each variable and constant is a very good way to approach an understanding of the equation as a whole.

> By the time you reach the end, you can't remember what the beginning did, so you have to go back and forth all the time.

That's temporary, it only lasts until real familiarity sets in, until the relationships become instinctive. It's like the old joke about prisoners who tell jokes by number.

Re: Is there an excuse for short variable names?

#22
I think that the second most upvoted answer is right on spot: variables that a short lifespan should be shorter than the ones having a long lifespan.

Of course when you're working in a functional language you basically only have short lived "variables" (they're not even "variable" but whatever). Even better yet, in some languages you don't even need that many variables.

The recent voted article about the guy refactoring Java code to Clojure was precisely an example of that.

So why even have "variables" when you can very often do without!?

Re: Is there an excuse for short variable names?

#23
Variable name length should be inversely proportional to scope visibility. Names in complicated math should also be kept very short. I like to get the best of both worlds by renaming just before the formula:

    var G  = Physics.Gravitational_Constant;
    var M1 = Physics.Mass_of_Earth;
    var M2 = Simulation_Constants.Mass_of_Asteroid; 
    return (G * M1 * M2) / (r*r);

Re: Is there an excuse for short variable names?

#24
post #18
post #8

Simple solution: in a program source, create a very clear comment header that won't be missed, that explains the meanings of the variables. Also, even though physicists can use any names or lengths they like in their papers, they seem to prefer concision: f = G M1 M2 / r^2 If the reader understands the math, short variable names aid comprehension, not the reverse.

You mean a comment header like http://futureboy.us/frinkdata/units.txt ? No matter how clear and detailed, there comes a point when nobody is likely to remember much of it. (And that would be an exemplary example of clarity. Read it if you don't believe me.) There is an upper limit to how much state we can stuff into our head. We can memorize things for longer. But unless we will amortize that state over many, many u…

> You mean a comment header like http://futureboy.us/frinkdata/units.txt? No matter how clear and detailed, there comes a point when nobody is likely to remember much of it.

Yes, but I'm not sure that's a very good example. There's a lot going on there -- things not really soluble using multiple-character variables.

> There is an upper limit to how much state we can stuff into our head.

Yep. It's why we have computers. :)

In case that seemed flip, consider this -- if I want to verify that I am using some program variable X in a consistent way, all I need to do is globally search for it and evaluate each case. Modern programming editors will happily list every instance of that variable's use, so I can make sure I'm being consistent. In such a case, a multiple-character variable would likely tend to obscure the issue and complicate the search.

Re: Is there an excuse for short variable names?

#25

I think that the second most upvoted answer is right on spot: variables that a short lifespan should be shorter than the ones having a long lifespan. Of course when you're working in a functional language you basically only have short lived "variables" (they're not even "variable" but whatever). Even better yet, in some languages you don't even need that many variables. The recent voted article about the guy refactor…

> So why even have "variables" when you can very often do without!?

In many of those cases, as often as not, the problem of variable names is replaced by the problem of function names, and we're back to square one.

Re: Is there an excuse for short variable names?

#26
post #12

Ugh. He's complaining about commonly known physics abbreviations. Short variable names are fine as long as they are descriptive. The key thing to keep in mind is descriptive to you may not be descriptive to someone else (or future you for that matter.) You can even scrape by with naming the full version in declaration. nothing worse than a cryptic name you cant figure out at first glance like in this instance.

[deleted]

Re: Is there an excuse for short variable names?

#27
post #5
post #3

Earlier quoted context omitted.

di[ctrl+space] = Math.Sq[ctrl+space](xD+[ctrl+space] ... robo[ctrl+space][index].ohG[ctrl+space] Every editor I've used in about 10 years has had an excellent autocomplete feature. I've never had to type out such long variable names.

Physicist here. I never have to read such long variable names, which would make it much more difficult to spot bugs. I do undertand that long variable names have their place but, when it comes to programming numerical code which is a translation of actual equations, shorter names make it much easier to read and spot mistakes. I do wish that I could use a programming editor that could look like a TeX output on the scr…

> I do wish that I could use a programming editor that could look like a TeX output on the screen though ...

For other readers (I suspect you already know this), Mathematica and Sage (and other environments) do a pretty good job of providing TeX-like feedback on what you've just typed in (but not keystroke-by-keystroke, which would be nice).

For those unfamiliar with Sage:

http://www.sagemath.org/

My Sage tutorial:

http://arachnoid.com/sage

Re: Is there an excuse for short variable names?

#28
The root problem seems clearly (to me) that he is the only programmer maintaining a system whose original authors are no longer available. The life of a software system is very much in the minds of the people who are making it, and when they are gone, this is a kind of death.

This has nothing to do with length of variable names, although it is tempting to ascribe one's frustrations with a codebase to lack of skill on the part of the original programmers, rather than lack of access to their thinking.

Re: Is there an excuse for short variable names?

#29
post #5
post #3

Earlier quoted context omitted.

di[ctrl+space] = Math.Sq[ctrl+space](xD+[ctrl+space] ... robo[ctrl+space][index].ohG[ctrl+space] Every editor I've used in about 10 years has had an excellent autocomplete feature. I've never had to type out such long variable names.

Physicist here. I never have to read such long variable names, which would make it much more difficult to spot bugs. I do undertand that long variable names have their place but, when it comes to programming numerical code which is a translation of actual equations, shorter names make it much easier to read and spot mistakes. I do wish that I could use a programming editor that could look like a TeX output on the scr…

> I do wish that I could use a programming editor that could look like a TeX output on the screen though ...

This was one of the design goals of the Fortress project

http://labs.oracle.com/projects/plrg/Publications/fortress.1...

Scroll down to section 2.3 'Rendering'.

Sadly the project is now defunct.

Re: Is there an excuse for short variable names?

#30
An argument that usually lets programmers understand why physicsists do this: to a physicist variables like x (position), v (velocity), p (momentum), R (radius) are as clear as i,j,k,l to a programmer. Using the longhand would not improve readability for them, just like using arrayIndex instead of i would not improve readability for a programmer. In fact for a physicist it is much easier to read the short variable names, since that's what we always use, and it makes it easier to recognize an entire expression in the blink of an eye. It also keeps expressions on one line instead of 5. Another thing is if you're not a physicist, chances are very good you are not going to understand the code anyway, or at least not without consulting a physics text or paper, in which they will use exactly the same variables x,p,v,R, and now you're glad that these correspond exactly to your program's variables. If you update an equation like T = dE/dS to temperature = infinitesimal_change_in_energy / infinitesimal_change_in_entropy, you have gained only superficial readability. If you don't understand the former you will not truly understand the latter either.
Post reply on HN