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

121–130 of 175 posts

Re: A Guide to Naming Variables

#121

Post by rootlocus »

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

If the function doesn't have side effects (and even if it does), the IntelliJ IDEA debugger will gladly evaluate the function call and show you its result for java applications. PyCharm can also do this for python.

Re: A Guide to Naming Variables

#122

Post by ArkyBeagle »

ambulancechaser wrote: post #62
cagey wrote: post #55

Earlier quoted context omitted.

I too abhor single-letter variable names. My personal convention: minimum identifier length==2. {i,j,k}->{ix,iy,iz}, c->ch.

I'm all for descriptive names but do you really not like iterator variable names like i,j,k or x,y,z? You prepend them i (for integer i suppose)?

In FORTRAN 64, variable names were significant. I was an integer, F was a float, that sort of thing. This created habits that persist to this day.

Re: A Guide to Naming Variables

#123

Post by andrewfromx »

andrewfromx wrote: post #3

when it's coding as fast as humanly possible, the last thing I want to do is slow down to think of good var names. I'll often just name something "foo" if I can't think of a good name and come back and rename it later. Sometimes it's a little better than foo but still not perfect but I'll leave that and move on to something else. I really don't like the idea that code must be perfect. Code is never perfect.

I remember working with one developer who would get in at 10:30 AM, think about ONE variable name in ONE method until lunch, take a 2 hour lunch break, and THEN maybe code one perfect method. Sorry not sorry there is a happy medium here. My code is not unreadable. I like to name something "curIndex" and move on with my life.

Re: A Guide to Naming Variables

#124

Post by ArkyBeagle »

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…

I think cliches are awesome.

Re: A Guide to Naming Variables

#125

Post by dragonwriter »

logicallee wrote: post #99
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…

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…

ISTR several environments that have a direct reference to the result of the previous computation, including at least one that uses "it" to refer to that result.

OTOH, I don't remember which one does that, and its a pretty-much completely search-proof topic.

Re: A Guide to Naming Variables

#126

Post by rootlocus »

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…

I find it funny the author considers `result` to be cliche, and renames it to `resultToReturn` which is obviously so much better.

Re: A Guide to Naming Variables

#127

Post by maxxxxx »

rootlocus wrote: post #121
maxxxxx wrote: post #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…

If the function doesn't have side effects (and even if it does), the IntelliJ IDEA debugger will gladly evaluate the function call and show you its result for java applications. PyCharm can also do this for python.

The Visual Studio debugger can do that too but that works for only for functions without side effects that can be executed repeatedly. This is often not the case.

Re: A Guide to Naming Variables

#128

Post by bobwaycott »

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, as a rule, only use single-letter vars when iterating over an emumerable, in which it is clear what the single-letter var represents. Outside of that, never. The single-letter var also is usually the first letter of whatever actual items are being iterated over. Something like:

    for c in customers:
        do_something(c)

Re: A Guide to Naming Variables

#129

Post by Nullabillity »

BinaryIdiot wrote: post #60
Nullabillity wrote: post #53

Earlier quoted context omitted.

> It makes scanning, grepping, etc all so much easier. Or you could use a decent editor, that keeps track of variable scopes.

> Or you could use a decent editor, that keeps track of variable scopes. Are you suggesting doing a find / grep inside the context of a current scope? Or just color codes / indents / marks in some way the scope? That works to a degree if an editor can do that though that still doesn't ultimately help the fact that it's a single file that you may need to search around for something. Plus not every environment will hav…

> Are you suggesting doing a find / grep inside the context of a current scope? Or just color codes / indents / marks in some way the scope? That works to a degree if an editor can do that though that still doesn't ultimately help the fact that it's a single file that you may need to search around for something.

At least IntelliJ will highlight all uses of the currently selected variable/method/whatever, and will quickly allow you to jump to any of them.

If I'm searching for something by name then it's almost always because it's in use somewhere, and a ctrl+click will take me there instantly, without getting bogged down in false positives.

> Plus not every environment will have your favorite editor setup how you like it.

Sure, but how often do you actually have to work with your regular codebase in such an environment? Sure, such a rule has its uses, but in 97% of cases it's just a symptom of a poor editor setup.

Re: A Guide to Naming Variables

#130

Post by munificent »

philwelch wrote: post #101
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…

Call it "result":

- "val" in "retval" carries no meaning. Everything stored in a variable is a value.

- "ret" is an annoying abbreviation for "return" that makes it harder read.

- "return" focuses on an implementation detail—that the function produces its value using the language's "return" statement. It doesn't matter how the result is emitted, just that it is.

If a function is simple enough that the variable storing the result doesn't need a more specific name, "result" is a good default. You could call it "sum" here, but that shadows the function itself—a common problem for result variables—and doesn't really tell us anything we don't already know. We know we're inside a "sum" function.

Post reply on HN