Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A Guide to Naming Variables

a-nickels-worth.blogspot.com

Post reply on HN
Print view View original

31–40 of 175 posts

Re: A Guide to Naming Variables

#31

Post by owenconti »

rectang wrote: 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 can't stand that. I like using names that don't make me think about what the variable means.

Re: A Guide to Naming Variables

#32

Post by mixmastamyk »

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, but I often find these names useful, combined with a good function name and docs of course. Thoughts?

Re: A Guide to Naming Variables

#33

Post by theandrewbailey »

codesnik wrote: post #30

"rather than the elliptical vagueness of Romance languages like English" - what?

I had a few problems with that, too. English isn't a romance language (it stole a lot of romance vocabulary, though). I guess that the author eventually gets around to explaining what he means: too much vocabulary that doesn't break down into simpler, understandable words. It reminds me of the linguistic contortions you need to do in order to write like the Thing Explainer.

Re: A Guide to Naming Variables

#34

Post by xixi77 »

rectang wrote: 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…

TBH, when reading others' code, I would generally prefer a shorter name to a similarly informative longer name, as it definitely speeds up recognition.

There are a few situations when this is the case: on top of my head, (i) function arguments, (ii) implementations of mathematical formulae that already have standard conventions for notation, (iii) cases when longer variable names are not well chosen and don't tell us much (e.g. his "processElements" function is far, far easier to read than "doSomethingWithCollectionElements"), (iv) situations when there are multiple long names that only differ in the last few characters -- again, I would much rather see "in_x" and "in_y" than "ThisHereInputCoordinateX" and "ThisHereInputCoordinateY", particularly if these are a part of a formula with a few other variables involved.

Might be just me and how I read things, of course -- e.g. I usually print stuff in the smallest readable font, so that I can see more of the logic at the same time, and this is definitely not the case for all people.

Re: A Guide to Naming Variables

#35

Post by mixmastamyk »

6502nerdface wrote: post #19
squeaky-clean wrote: post #14

Earlier quoted context omitted.

A convention I've always done for this is to just use a plural name. There are fewer errors based on mixing up the names than you'd think, and it's very readable. for fruit in fruits: assert fruit is not 'apple' print(fruit) assert 'banana' not in fruits etc. Especially in Python, it makes code flow very much like English. Edit: It also goes with the "don't put the type in the name" point, which I agree with in most…

I've always considered it a dangerous idiom in dynamic typed languages like Python to create identifiers that differ from each other by only a single character (fruit/fruits), point to completely different objects, and are used in close proximity to each other. It's just asking for a hard-to-detect typo that will blow up at runtime.

Hmm, don't think that actually happens very often, because it is so readable this way.

Re: A Guide to Naming Variables

#36

Post by euphemize »

mixmastamyk wrote: post #32

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…

Agreed with you. Perhaps if you're using temp or tmp, something could be done better, but I see no harm in using the others. If you're counting things, a variable named "count" sound perfectly reasonable to me.

Re: A Guide to Naming Variables

#37

Post by nilved »

rectang wrote: 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…

Have you considered not writing functions longer than 3 lines?

Re: A Guide to Naming Variables

#38

Post by guscost »

mixmastamyk wrote: post #32

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 this part is a bit ridiculous. A good reason to avoid "str" is because something more descriptive (and probably not much more verbose) would be helpful to see instead. "Because it's overused" is a silly reason, I would hope the author merely intends to criticize inappropriate overuse of these minimally-descriptive placeholder names.

When I'm mapping an array of line items with lodash, the predicate parameter is usually named "item" because it is short and perfectly adequate in context.

Re: A Guide to Naming Variables

#39

Post by kbenson »

squeaky-clean wrote: post #14
RodericDay wrote: post #6

In dynamic languages, like Python, I think it's often good to call variables something like `fruit_list`, to quickly pick up on a bug where ie: `fruit_list == {'apple'}`.

A convention I've always done for this is to just use a plural name. There are fewer errors based on mixing up the names than you'd think, and it's very readable. for fruit in fruits: assert fruit is not 'apple' print(fruit) assert 'banana' not in fruits etc. Especially in Python, it makes code flow very much like English. Edit: It also goes with the "don't put the type in the name" point, which I agree with in most…

Funnily enough for your example, depending on whether you are describing different types of fruit or multiples of one type of fruit, the plural of fruit may be "fruit". :)

> It also goes with the "don't put the type in the name" point, which I agree with in most cases.

Is that a problem in practice in Python? That's the whole reason Perl uses different sigils to denote different types of variables, which Python specifically rejected. Personally I prefer being able to tell if something is a collection, and which core type of collection, at a glance (barring refs).

That actually does allow the same name to be used as a scalar, an array and a hash, but it's considered very bad practice.

    # Valid perl, but will get you nasty looks from coworkers
    my @fruit = qw( apple banana banana apple apple mango apple mango banana );
    my %fruit;
    for my $fruit ( @fruit ) {
        $fruit{$fruit}++; # increment %fruit hash item $fruit
    }

Re: A Guide to Naming Variables

#40

Post by euphemize »

rectang wrote: 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…

Also agreed. I will use single-letter variables like "c" or "x" occasionally for lambdas or anonymous functions, but that's about it. "lambda x: not x" in python - anything longer I think should be descriptive.
Post reply on HN