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

101–110 of 175 posts

Re: A Guide to Naming Variables

#101

Post by philwelch »

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, 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 end
    sum
  end
would, due to lexical scoping, make it impossible to call the method recursively.

Re: A Guide to Naming Variables

#102

Post by blastrat »

dragonwriter wrote: post #66
newobj wrote: post #63

Since when is English considered a romance language? I thought it was majority Germanic in origin.

English is a Germanic language with a strong Romance influence, thanks to the Norman Conquest. (That is to say, you are quite correct that it is not a Romance language.)

it's always funny to me when people talk about the Norman Conquest with respect to Romance Languages... the Normans were Vikings, Germanic. In terms of Romantic influences, it is the Normans who were conquested by Latinate language :)

Re: A Guide to Naming Variables

#103

Post by psylence519 »

snarfy wrote: post #91
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…

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.

Re: A Guide to Naming Variables

#104

Post by squeaky-clean »

kbenson wrote: post #39
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…

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 speci…

> Is that a problem in practice in Python?

> I prefer being able to tell if something is a collection, and which core type of collection, at a glance (barring refs).

Not really a problem, but if you're writing more than a one-off script, such as a module you plan on sharing, it may be common that you get a mixture of concrete types coming in depending on the app and platform. I think in practice, it's actually beneficial to assume you do not know the core type of collection (if your operations will work with many/all of them).

For example, a range object or generator in Python 3, but a list in Python 2. And then someone else comes along and uses your modules with sets.

So with "fruits" (or something like "fruit_iter" for anyone who disagrees with plural naming), you know that you can safely iterate through it. But you may not be able to do random access, or reassignment of elements. There might be times when this matters, in which case you'd want to enforce a specific type.

The only thing I do not like about this is that in Python strings are also iterables. So the difference between passing "Apple" and ["apple"] can be quite large, and yet your program will iterate through "a", "p", "p", "l", "e" with no complaints. The worst experience I've had with this was working with a web API that would return either an array of strings, or only a string if there was one result (not a 1-element array), or a dictionary of objects if there were many results. 99% percent of the time it returned the array of string, and since strings and dictionaries are iterable, it took me a while to notice the bug.

I ought to learn Perl, because that's pretty cool. You're right that that example is terrible to read, haha, but I'm sure there are scenarios where it's helpful.

Re: A Guide to Naming Variables

#105

Post by Camillo »

> Most names should be Teutonic, following the spirit of languages like Norwegian, rather than the elliptical vagueness of Romance languages like English. Norwegian has more words like tannlege (literally "tooth doctor") and sykehus (literally "sick house"), and fewer words like dentist and hospital (which don't break down into other English words, and are thus confusing unless you already know their meaning).

Not only is this vaguely racist; it's also wrong, which is worse.

- English is, in fact, a Germanic language.

- Using more specific words (and English has lots of words) is the opposite of vagueness. A "sick house" could be a house that contains sick people, a house that is sick itself (rotten beams?), a noble family ("house") whose fortunes have turned, etc. A "hospital" is, unambiguously, a facility where the sick are given professional care. Of course, in a different timeline "sickhouse" could have been the word for "hospital", but then it would have been a word of its own, taking up the same amount of space in your mental dictionary as "hospital" does.

- Romance languages are, arguably, less vague even in their grammar. You know that thing where you just jam two words together and call it a day? You see very little of that in Romance languages. Instead, you put a preposition in there, which forces you to be more specific about the exact way in which the two things are related.

- Of course, a "Teutonic" fan would then say that this is a problem with Romance language, and the ability to jam words together is what makes a language truly rich. (Because it's easier to form new words? In which case, see item 2.) And sure, it's ok to have preferences. But if you're going to be a Grammar Nazi, or a literal Nazi, you better have a clue what you're talking about.

Re: A Guide to Naming Variables

#106

Post by lgunsch »

mixmastamyk wrote: post #35
6502nerdface wrote: post #19

Earlier quoted context omitted.

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.

I written python for the last 4 years, and I've never had typo problems of that nature. I find the plural form to be so idiomatic it is expected and easier to understand.

Re: A Guide to Naming Variables

#107

Post by logicallee »

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, I agree with you completely! Maybe not with val or value, but with everything else.

One of the best ways to calculate something is to build it up line by line. It makes the code really easy to follow. Also see my other comment about languages lacking "it", "that", etc. Result is sometimes a good substitute!

Re: A Guide to Naming Variables

#108

Post by squeaky-clean »

DiabloD3 wrote: post #18
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…

That has always been a Java thing to me. I see it a lot in Sunacle, Apache, and Google originated code (which, for some reason, all three have their own different culture on how to write Java, but it's kind of subtle).

Maybe! My first real coding gig was Java, so I built up a lot of habits there. I've noticed the JetBrains IDEs do this style of naming and inference automatically. I haven't written Java in a long time, but it would make sense if that's where I picked it up. I do like the convention very much though.

Re: A Guide to Naming Variables

#109

Post by drdeadringer »

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 agree with you.

Two years from now, I'm not going to be able to remember "c" from "v" without having to think harder than I have to.

If I name the variables something like what they actually mean or do, however, that's much better. I know what "particle_count" is more so than "p".

Re: A Guide to Naming Variables

#110

Post by eevilspock »

Author fails to follow own advice:

  int printFirstNPositive(int maxToPrint, Collection c)
The method name uses "N", but the param for N is named "maxToPrint". Confusing and also violates his/her wasted space rule.

Instead:

  int printFirstNPositive(int n, Collection c)
I think the short variable names "n" and "c" are fine since they are part of the method signature and have unambiguous meaning, and also because the implementation is so short (so no problem remembering that n and c are the inputs.
Post reply on HN