Is there an excuse for short variable names?
programmers.stackexchange.com
programmers.stackexchange.com
Eventually I put a big comment at the top that to understand the code you needed to draw the picture, and named my variables x and y. About a page of code later, I was done. And when I has to tinker with it a couple of years later my first reaction was to wonder WTF I was thinking, wince in memory of how I had struggled with it, then I drew the picture, and I was amazed at how easy it was.
The rule is not that you need long or short variables. You need meaningful ones. A short variable name is inherently ambiguous, which can lead to confusion and mistakes. Thinking through anything with a long-variable name abuses your working memory, limiting how complex your thoughts can be.
It is a trade-off. Use the right one for your code. For me, index variables are short, and so are any variables that refer to math concepts that I understand well. Otherwise I use (concise if possible) descriptions without any abbreviation, separated by underscores.
"Once you understand the math, the length of the variable names is irrelevant. Do others a favor and leave a citation (in a comment) to some relevant description of the math, though, if you had to learn it!"
The problem is that the same notation is often used in different parts of math in different ways. You sometimes need to clarify. (Except in the case of differential geometry - there the notation is so horrible that you should find a different job! I only partly kid...)
Conversely even if you aren't using a standard math notation, meaningless names and a simple labeled diagram can often make something unambiguous in a way that no amount of verbiage in variable names can hope to do.
var G = Physics.Gravitational_Constant;
var M1 = Physics.Mass_of_Earth;
var M2 = Simulation_Constants.Mass_of_Asteroid;
return (G * M1 * M2) / (r*r);and in the case the changes in energy or entropy are not so infinitesimal, the semantics of the variable name can cause all sorts of troubles
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.
There really is no logical reason to do this, other than established practice.
I've found that even scientists and mathematicians can be closeminded enough to get angry when you suggest that they're being inefficient and wasteful, and their conventions are crap.
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. 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.
Also in this case you are wrong. With a compact notation you can think more complicated thoughts than you can with a verbose one. The downside is that a compact notation requires more from the person reading it. The tradeoff is correct, and the domain expert is not necessarily wrong.
Your domain expertise is maintaining a lot of very precise instructions for a variety of different problems. For you, constant signposts are an assistance. For a domain expert in their domain of expertise, they are overhead.
For a domain expert in their domain of expertise, [long explicit names] are overhead.
Once you pass a certain threshold of complexity and/or time-investment, a well-designed program becomes its own domain of expertise. At that point there is great leverage to be had in finding a compact notation suitable for the recurring concepts of the system. In some ways, finding such a notation is how one ensures that the system has a good design and will keep it. As you point out, it (critically) is what enables us to keep more complex things in our heads. It also becomes an intimate part of the creative process – a good notation suggests new concepts and hints at how the system should grow.
Long explicit names are exactly what you don't want when it comes to the core concepts of a well-designed system. They are useful for things that aren't familiar and so need to be spelled out. But in a well-designed system, the most important concepts are familiar and it is a poor use of our limited cognitive capacity to constantly spell them out, for much the same reason that we prefer to say "gas" instead of "liquid hydrocarbons". Since cognitive capacity is our principal bottleneck in software, this is a big deal.
I think your point is a very valid one. I guess when I try to read a paper that's "way over my head" academically, it's fair that the authors don't care about me.
But I don't think they know its tradeoff. The way I know this is by reading the majority of intro / mid level textbooks I've had to deal with as a freshman. At that point you're not nearly a domain expert, but the texts are written in the same way.
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.
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 uses, the effort is not worthwhile.
That said, if we have taken the effort to memorize it, there is no reason not to leverage the already spent effort.
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.
you don't have to do this while you're writing the code, often-times just hammering the code out gets you something running, but then doing this after the fact really helps.
Assuming everyone knows your equation and what your variables mean is a terrible idea. Unless your method is less than 10 lines and you explain all the variables in a comment... just write stuff out. Text is free. Don't go crazy, but 4-8 characters won't kill anyone and may well prevent bugs.
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.
I am not completely sold on this, but for example LLVM has a lot of 1 character variables where 'I' is always the instruction you're working on, 'F' is always the function you're compiling, 'B' is the current basic block you're processing, etc.
Having worked on several compilers over the year, it's certainly not much worse than other practices I have seen like using 't1' and 't2' to refer to the two instruction temporaries you just created, or 'insn' for the instruction you're currently examining.
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.
As mentioned elsewhere in this thread, short-lived names can often be short, too. In some cases they are little more than placeholders. An example is an index for a for-loop that is in fact a "for-each" loop when the language lacks the latter and the index does not have much of a meaning of its own.
//for every
for(int i = 0; i < things.length; i++){
//there's a
dx = x - tx/mf;
dy = y - ty/mf;
}
//but then for every
distanceToTarget = Math.SquareRoot(xDistance*xDistance + yDistance*yDistance)
//there's a
for(int index = 0; index < robotsCurrentlyInField.length; index++)
{
robotsCurrentlyInField[index].ohGodMyFingersAreBleeding(distanceToTarget);
} di[ctrl+space] = Math.Sq[ctrl+space](xD+[ctrl+space] robo[ctrl+space][index].ohG[ctrl+space]
Your eyes just start to glaze over (or at least mine do).
If you're only ever using one coordinate system, just use thing.x and thing.y or thing.h and thing.v, maybe with a comment that explains that these are in transformed and scaled units. Your eyes will thank you. :-)
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:
My Sage tutorial:
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.
http://37signals.com/svn/posts/3250-clarity-over-brevity-in-...
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!?
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.