Live data from Hacker News

A Guide to Naming Variables

a-nickels-worth.blogspot.com

111–120 of 175 posts

Re: A Guide to Naming Variables

#111
post #4

Most of this, even if it's not my preference, I would never bother arguing with. But I have a question about a practice that is tremendously widespread. I have real trouble with single-letter variable names like "c", for any function more than, say, 2-3 lines. I scan the code and it increases my mental load because I have to remind myself what it means. Obviously a lot of people don't have problems with this, but I d…

I agree. It's not a mental tax to read a word we recognize. It's not like we have to sound it out letter by letter, we recognize its form at a glance. It's more taxing to maintain a mapping for an inherently meaningless single character. Although there are some single characters that do have meaning due to long time convention such as 'i'.

What about variables which are inherently "meaningless", i.e. they're only given a name in order to distinguish them from each other?

For example:

    function flip(func) {
      return function(x, y) {
        return func(y, x);
      };
    }

    function compose(func1, func2) {
      return function(x) {
        return func1(func2(x));
      };
    }
Code like this is completely generic; we know absolutely nothing about `x`, `y`, etc. other than they're distinct arguments; we don't even know their type (they're "parametrically polymorphic").

Would it be better to call them something like `arg`, or `arg1` and `arg2`? The fact they're arguments is obvious, so that would be just as redundant as something like `int int1 = ...`.

This kind of generic "plumbing" appears all the time when using a functional style, where our function's job is to take in a bunch of values and combine them in some way, without caring what they are.

Re: A Guide to Naming Variables

#112

A good guide, but I didn't like this part: Avoid Over-used Cliches In addition to not being Teutonic, the following variable names have been so horribly abused over the years that they should never be used, ever. val, value result, res, retval tmp, temp count str Cliches? If you are trying to communicate, these names are well known ways to do that. If there is something more specific to put in there, by all means, bu…

Yeah, the problem with outlawing "retval" in particular is that there's no good variable name in this situation: int sum(Collection c) { int retval = 0; for(int i = 0; i What the hell should I call retval? If I call it sum, that's redundant with the method name. Also, while it might work in Java, it would be more dangerous in a language like Ruby where the equivalent code: def sum(c) sum = 0 c.each do |e| retval += e…

I'd call your method SumCollectionInteger and call your return value sum. This doesn't really work if you use function overloading though.

Re: A Guide to Naming Variables

#113
post #4

Most of this, even if it's not my preference, I would never bother arguing with. But I have a question about a practice that is tremendously widespread. I have real trouble with single-letter variable names like "c", for any function more than, say, 2-3 lines. I scan the code and it increases my mental load because I have to remind myself what it means. Obviously a lot of people don't have problems with this, but I d…

it's obvious that computer scientists have COMPLETELY dropped the ball by not figuring out a way for anyone to write "it", "that", "which" and so on and have the IDE and language disambiguate it into what you were JUST talking about. This is stuff that my great-grandparents should have been suggesting some time after Ada Lovelace wrote about the analytical engine in 1842 or 1843. Not something I should be writing abo…

"Computer scientists" don't have an opinion much about a particular IDE; if you want that functionality in an IDE, it might be a shorter path to cause it to exist in the first place.

I bet it's harder than you think.

Also, IDEs are better than they used to be - I stopped using them because they caused problems in the late 20th Century. There was a proliferation of them until Eclipse got good enough to not cause problems. Eclipse still had less text editing power than some just-plain-old-editors from the 1980s. So I only use an IDE if it's the only logical choice for a development system. It usually isn't.

If, as in one shop at which I worked, you constantly write, say EMACS macros and use them a lot, you will evolutionary drift away and it will make your team more and more ... linguistically isolated, which has costs in onboarding and this sort of mild narcissism about your setup.

I think that dependence on an IDE is mostly a weakness, not a strength.

Re: A Guide to Naming Variables

#114

Good advice about variable names (though surely "dentist" isn't all that obscure), but the example function suffers from the boilerplate that the author rightly says is a problem. Looking at the Java Collection interface, the removeIf() description sounds like it actually modifies the Collection rather than creating a new one. Is there a way in Java to do the equivalent of the following Haskell (I'm being lazy and no…

In Java it's `xs.stream().filter(x -> x > 0).limit(n)`. That's a fairly new API though, so it's not all that heavily used.

Re: A Guide to Naming Variables

#115
post #4

Most of this, even if it's not my preference, I would never bother arguing with. But I have a question about a practice that is tremendously widespread. I have real trouble with single-letter variable names like "c", for any function more than, say, 2-3 lines. I scan the code and it increases my mental load because I have to remind myself what it means. Obviously a lot of people don't have problems with this, but I d…

For 'local utility' vars - things like loop counters, short lived array indexes/pointers, collections data (the ubiquitous k,v for 'key', 'value') - things like that, even if a block of code whose scope they are tied to is in a 15-20 line range I'm totally fine with single-letter names. Also, on the flip side, if say my chunk of code is solely dedicated to operating on a single object I'm totally fine using a one-let…

Personally I like to make even my short lived variables more verbose. If I'm iterating through a list of things, I'll call my loop var an iThing. It makes it immediately obvious if you're doing something wrong if you write NotAThingList[iThing].

Re: A Guide to Naming Variables

#116
post #4

Most of this, even if it's not my preference, I would never bother arguing with. But I have a question about a practice that is tremendously widespread. I have real trouble with single-letter variable names like "c", for any function more than, say, 2-3 lines. I scan the code and it increases my mental load because I have to remind myself what it means. Obviously a lot of people don't have problems with this, but I d…

it's obvious that computer scientists have COMPLETELY dropped the ball by not figuring out a way for anyone to write "it", "that", "which" and so on and have the IDE and language disambiguate it into what you were JUST talking about. This is stuff that my great-grandparents should have been suggesting some time after Ada Lovelace wrote about the analytical engine in 1842 or 1843. Not something I should be writing abo…

Perl's $_ probably comes closest to what you're asking for.

Re: A Guide to Naming Variables

#117
post #91

Earlier quoted context omitted.

bool productPricingUpdatedAfterDeliveryFailedButEmailSent = false; I've seen variables with names like the above. It would have been better explained in a comment and used a short variable name. Unless you like typing it forces you to use an editor with autocomplete (which you are crazy not to use one), and IMO pollutes the code. Variables should be easy to type and read. It's a trade off.

If you need that much information about a variable, I would expect, in general, that the context it lives in is doing waaaay too much and should be broken up.

100% agree! I always try and remember the Single-Responsibility-Principle.

Re: A Guide to Naming Variables

#118
post #4

Most of this, even if it's not my preference, I would never bother arguing with. But I have a question about a practice that is tremendously widespread. I have real trouble with single-letter variable names like "c", for any function more than, say, 2-3 lines. I scan the code and it increases my mental load because I have to remind myself what it means. Obviously a lot of people don't have problems with this, but I d…

Beats me. So this is something that hasn't gotten any better for you over time?

You should look at old school DSP code some time. :) Some of that is translating from variable names in mathematics papers.

Also - for us old guys, you could take typing or you could take a math class, so many of us never really learned to type properly. So typing can be an actual consideration. Schools adapted to this later.

Re: A Guide to Naming Variables

#119
post #91
post #4

Most of this, even if it's not my preference, I would never bother arguing with. But I have a question about a practice that is tremendously widespread. I have real trouble with single-letter variable names like "c", for any function more than, say, 2-3 lines. I scan the code and it increases my mental load because I have to remind myself what it means. Obviously a lot of people don't have problems with this, but I d…

bool productPricingUpdatedAfterDeliveryFailedButEmailSent = false; I've seen variables with names like the above. It would have been better explained in a comment and used a short variable name. Unless you like typing it forces you to use an editor with autocomplete (which you are crazy not to use one), and IMO pollutes the code. Variables should be easy to type and read. It's a trade off.

Well, there is a middle ground between 'c' and writing a novel in a variable's name.

Single letter variable names are okay for loop iteration variables, or e.g. x and y when dealing with 2D coordinates (i.e. if within the context a single letter name has useful meaning - I suspect physicists and the like find themselves in that situation often).

But trying to give variables short names (which is a good thing) should not be an excuse to give them obscure names.

As an extreme example, think of Perl, which has a "default variable", that has basically no name at all ($_). When used properly, one can, I guess, write marvelously succinct code, but I try to avoid it and use explicit names.

The older I get, the more I tend to agree with Aristotle's general approach to ethics: Avoid extremes, seek a middle ground/moderation. I am not sure if it is a good ethical principle, but in many cases where ethics don't matter, it is a good guideline.

So for Identifiers: Be short, but clear. When in doubt, choose clarity over brevity, but keep in mind that what might be clear to you could be highly obscure to somebody else. If at that point I was still in doubt, I would pick a name based on how the variable is used: The more rarely it used, and the more significant it is to the program, the more reasonable it becomes to use a verbose name, especially when it is a global variable. For locals, one can always use a short name and a comment to explain what role it plays.

Re: A Guide to Naming Variables

#120
As a German I totally agree with teutonic naming. Who doesn't love words like "Umsatzsteuervoranmeldung".

However, I disagree with the chapter "Remove Thoughtless One-Time Variables". I much prefer having a variable I can check in the debugger than having the result of some function passed into another function without being able to see what the value is. Any halfways good optimizer will remove the varibale anyway so there is no performance hit.

Post reply on HN