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

91–100 of 175 posts

Re: A Guide to Naming Variables

#91

Post by snarfy »

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.

Re: A Guide to Naming Variables

#92

Post by BurningFrog »

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…

What the function is returning should be clear from it's name.

Repeating that in the return value variable is then redundant.

I like naming my result variables `result`. It makes it clear when you first see it what it's for, without having to read the function to the end.

Re: A Guide to Naming Variables

#93

Post by pklausler »

Here's a tip along these lines: Use 'j' and 'k' for integral loop control variables, not 'i'. Both 'j' and 'k' are pretty high-value Scrabble letters and it's easier to search for their appearances in code. Apart from "break", they don't appear in the reserved words of common programming languages.

(And never use 'l' as a variable name; but you knew that already.)

Re: A Guide to Naming Variables

#94

Post by dragonwriter »

bshimmin wrote: post #84
dwc wrote: post #56

Earlier quoted context omitted.

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".

If I'm iterating over a hash, it seems natural to use "k" and "v" or "key" and "value". Do other people use different names for these?

Yeah, there's lots of places where "value" is a well-accepted, clear, domain-specific language for a specific component of a construct, and thus using "value" is an excellent variable name.

(Similarly with data: lots of times, I've seen specs where a composite structure had a part called "data". Whether or not that is good naming in the spec, if I'm implementing the spec, using "data" for the element in the program corresponding to that part of the composite in the spec is clearly the exactly right thing to do.)

Re: A Guide to Naming Variables

#95

Post by robmcm »

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'}`.

I agree, the statement, "Pluralize the variable name instead of including the name of a collection type" massively increases the chance of referring to the wrong variables based on a simple typo. Also glancing at the code you have to pay extra attention to notice a single character.

In addition you have some words that don't pluralize well such as fruit or Lexus.

In my opinion the more verbose and unique you can make your variable names the better, even if that means adding redundant words.

Re: A Guide to Naming Variables

#96

Post by [deleted] »

blastrat wrote: post #89
ldmoray wrote: post #80

Earlier quoted context omitted.

I was under the impression that Hungarian was largely not recommended. I find it's redundant in strong static systems, and unhelpful in duck-typed systems.

As I said, READ THE PIECE, forget about what you think you already know. A discussion of what he actually said will be more interesting than a discussion of what you misunderstand. But in response to the point you raised, the purpose of Simonyi's system is NOT to avoid compilation errors (what you call redundant). The naming convention encapsulates precisely what programmers need to keep in their heads while they cod…

[deleted]

Re: A Guide to Naming Variables

#97

Post by ChemicalWarfare »

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…

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-letter name for those vars as well. Like say 'Person p' or 'WebView w' etc.

These are notable exceptions though, at least as far as I'm concerned.

Re: A Guide to Naming Variables

#98

Post by Stasis5001 »

wyldfire wrote: post #68

No mention of physical units? I always find it terribly frustrating when trying to read code that talks about physical dimensions like time and space without any clue as to what we're measuring. const int timeout = strtol(argv[2], NULL, 10); send_and_waitfor(&msg, timeout); When I read this code, should I take for granted that the caller and callee are using the same order of magnitude that's intended? If instead I s…

If possible, it's much better to handle physical units with the type system. If your timeout is a timedelta class (or duration/difftime/interval etc.), then this whole issue disappears.

Re: A Guide to Naming Variables

#99

Post by logicallee »

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 about in 2016. Yeah, okay, before always-on Internet it might make sense to have a small, unambiguous, self-contained grammar. The same is not true in 2016.

Here's how you calculate the absolute value of an integer: -> "if it's non-negative, return it; if it's negative return its opposite".

Here's how you calculate the absolute value of an integer if you're using any programming language written in 60 years: -> "if (argument There is literally no way to refer to "it" instead of "argument" except by changing "argument" to read "a" (or "i" or "x" or "$_" or...)

My point is that it's literally impossible to write "if (it > =0) return it; else return (it * -1)" if you've just mentioned "it" and you are there to check and correct the IDE if it's wrong. (Oh, wait, I should write "to correct the IDE if the IDE is wrong.")

I bet 90% of human languages have a way to refer to something you've JUST mentioned without repeating a word for it. (Words like it, that, etc.) I bet 0% of computer languages let you write "it" for the last thing you just referred to, even if there is literally 1 choice in the whole function, as in my absolute value example.

Ridiculous!

Re: A Guide to Naming Variables

#100

Post by bpicolo »

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

Single letter variable names are valid only in two cases: -loops (for i = 0; ...) -scientific variables, in which case they should probably be constants anyway (c = speed of light in a vacuum)

One of my biggest digs with typical mathematical/scientific notation is that reading equations where there are a number of things that are variables and other things that are constants with all one letter isn't great. I WISH we had used SPEED_OF_LIGHT in math class.
Post reply on HN