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

51–60 of 175 posts

Re: A Guide to Naming Variables

#51

Post by lmm »

jejones3141 wrote: post #42

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…

You can use the Java 8 streams interface, converting back and forth at the ends. Or there's a method in Guava-collections (won't be lazy though). Or you can use Scala.

Re: A Guide to Naming Variables

#52

Post by mmartinson »

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.

If you're doing fast prototyping or hacking for fun then mindless variable names make sense, but working on a production codebase that is or will likely be shared by others is a different situation.

There no argument for absolute quality in code, only value relative to its use case and context. Outside of correctness of behaviour and acceptable performance, the human-readability of code probably carries the most value in most situations.

Sure you can get by without it, but code that is readable will ultimately be more valued/reviewed/supported/improved.

Re: A Guide to Naming Variables

#53

Post by Nullabillity »

BinaryIdiot wrote: post #17
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 completely agree and I was a little surprised this blog post suggested that a simple 'c' was good enough. It's not good enough. While I understand the scope between two functions is different, if the variables can be unique then I say make them unique! It makes scanning, grepping, etc all so much easier. Unless it's a very obvious index for a for loop I am against single letter variable names. Hell even if it's a f…

> It makes scanning, grepping, etc all so much easier.

Or you could use a decent editor, that keeps track of variable scopes.

Re: A Guide to Naming Variables

#54

Post by Niksko »

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 guess what he's getting at here is that these variable names don't convey what the variable holds.

Let's say you're writing C and you want to return status information from processes as integers. Instead of:

> return retVal;

where retVal could be 0, -1 or -2 to indicate success or failure of the function, how about:

> return functionStatusCode;

? Or be even more specific (let's say the function tried to parse some text) with parserStatusCode.

All of those are more helpful than retval, because they give you some sort of idea as to what you're returning. You'r enot returning how many values were parsed, or some sort of information about what you parsed, you're returning the status of the parsing function.

The meaning of those values is probably a little harder to encode in the variable names (especially if there are many such values), but that's what the comments are for.

Re: A Guide to Naming Variables

#55

Post by cagey »

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

Re: A Guide to Naming Variables

#56

Post by dwc »

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 have mixed feelings. For a return value, retval et al are completely appropriate. Same for count. Tmp/temp borrow meaning from whatever they are a temporary for. These are all fine.

But "value" is horrible. You really don't know what it is? You might as well name it "variable". "Str" is in the same boat, unless it's short for "tmpstr".

Re: A Guide to Naming Variables

#57

Post by hnruss »

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…

Agreed. The part about 'c' seemed pretty contradictory, and without much explanation as to the exception.

Re: A Guide to Naming Variables

#58

Post by cubano »

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 would personally use the word "placeholders" rather then "cliches" and think most pros find them useful at times as they convey the proper temporary meaning of their use.

Re: A Guide to Naming Variables

#59

Post by Roboprog »

Niksko wrote: post #54
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 guess what he's getting at here is that these variable names don't convey what the variable holds. Let's say you're writing C and you want to return status information from processes as integers. Instead of: > return retVal; where retVal could be 0, -1 or -2 to indicate success or failure of the function, how about: > return functionStatusCode; ? Or be even more specific (let's say the function tried to parse some…

How about just "status" for the return code var name? It should be readily apparent that the var is "my" (the routine's) status [code].

Re: A Guide to Naming Variables

#60

Post by BinaryIdiot »

Nullabillity wrote: post #53
BinaryIdiot wrote: post #17

Earlier quoted context omitted.

I completely agree and I was a little surprised this blog post suggested that a simple 'c' was good enough. It's not good enough. While I understand the scope between two functions is different, if the variables can be unique then I say make them unique! It makes scanning, grepping, etc all so much easier. Unless it's a very obvious index for a for loop I am against single letter variable names. Hell even if it's a f…

> 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 have your favorite editor setup how you like it.

Post reply on HN