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

71–80 of 175 posts

Re: A Guide to Naming Variables

#71

Post by Niksko »

Roboprog wrote: post #59
Niksko wrote: post #54

Earlier quoted context omitted.

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

Ok, the 'function' part is not useful. And perhaps C was a bad example.

Let's say it's Python now, and for some reason I'm still returning 0, -1 or -2. Then 'statusCode' would be a good name for the variable I guess. The code part indicates that it's a codified version of the status. The smarter way might be to just return a status object or something, in which case perhaps 'statusObject' is better? Not sure.

I guess one thing I took away from the article is that it would be nice to be able to encode _how_ the data is being returned in the name of the return value. This saves me going and finding when the variable was created to get its type, or when the variable was assigned to.

Re: A Guide to Naming Variables

#72

Post by chimprich »

burkaman wrote: post #26
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 think it works here because you're in a context where there's just one collection. So you don't really have to remember what c means, you can see c.size() and think "this is the size of the collection", because in this context there's only one thing you could be taking the size of. If there were more than one collection, or we weren't using it in a way that makes it obvious it must be a collection, I would want a b…

> you can see c.size() and think "this is the size of the collection"

If you see collection.size(), you don't even need to think; the meaning is right there in your field of vision and you don't need to dedicate one part of your extremely limited short-term memory to remembering what c stands for. I can't see any advantage to shortening it to c, apart from saving a trivial amount of typing.

Re: A Guide to Naming Variables

#74

Post by snarfy »

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…

I find this less useful than using retval. I might have a half dozen variables like parserStatusCode in my function, but there is only one retval. What you return is defined by the function definition. It's extra boilerplate to call your variable parserStatusCode when then function is called getParserStatusCode() returning a type of ParserStatusCode.

Re: A Guide to Naming Variables

#75

Post by mmartinson »

Chromozon wrote: post #49
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.

Oh gosh. I really hope I will never have to work with you or ever use a product you have worked on. This is just terrible software engineering practice. You are doubling the amount of work you have to do and are creating a breeding ground for bugs. Remember this age-old wisdom "measure twice, cut once"? You are doing the exact opposite.

Great news for you, you are the master of your own destiny and never have to (:

The age-old wisdom holds of course for so many cases, but writing code isn't always software engineering. Wouldn't you grant that it would be a mistake to instil the value that all code written must be carefully crafted? There'd be a ton of missed opportunities for creativity if the act of coding was so sacred.

Re: A Guide to Naming Variables

#76

Post by Grue3 »

dwc wrote: post #56
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".

>You really don't know what it is?

What if I don't? Some of us program more abstract things than the others. For example I might want to write a function, that given a tree, and, well, a value, returns a tree where all nodes that have this value are removed. Doesn't matter that the tree in question will in practice be a tree of Flooblooators, I'd rather write reusable code that works for everything.

Re: A Guide to Naming Variables

#77

Post by Roboprog »

Bit of a tangent, but here goes...

It's a shame that C ... Java like languages became dominant, in that they "hide" identifier names after the type types, rather than putting the identifiers at the start of a line where they are more visible. (thank God for type inference, I guess, in newer languages)

Also, I find CamelCraps an impediment to scanning the names in code, as well. This is less of an issue when the name is one word, but "we" sure seem to like our AdjectiveAdjectiveAdjectiveNoun names in Java-land :-(

E.g. -

    qualifier qualifier AdjectiveAdjectiveAdjectiveNoun adjectiveAdjectiveAdjectiveNoun = new AdjectiveAdjectiveAdjectiveNoun(42)
Or was I supposed to @AutoInject that?

Please, just shoot me now.

Re: A Guide to Naming Variables

#78

Post by robmcm »

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.

I find this very confusing, and would much prefer to be explicit in adding the collection type.

This is also useful when you have two types of collections in the same place, such as an array and dictionary.

Re: A Guide to Naming Variables

#79

Post by korethr »

newobj wrote: post #63

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

English is a bastardized munge of a language, truthfully, with both Germanic and Romance parts. Initially it was a Germanic language, but after the Norman invasion of England, a great deal of Romance words were added to the language via the old French that the Normans spoke.

Re: A Guide to Naming Variables

#80

Post by ldmoray »

blastrat wrote: post #69

Not trying to convince anybody of anything, but as a public service to expand your mind, I strongly urge anyone interested in these types of ideas to FORGET WHAT THEY THINK THEY KNOW OR HAVE HEARD and to REREAD Charles Simonyi's (he invented WYSIWYG) seminal piece of his PhD thesis which now is some 40 years old. Forget what you THINK you remember about these ideas--they've been butchered in popular understanding--re…

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.
Post reply on HN