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

151–160 of 175 posts

Re: A Guide to Naming Variables

#151

Post by philwelch »

munificent wrote: post #130
philwelch wrote: post #101

Earlier quoted context omitted.

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

I usually go for "result", but that was also on OP's list. I wish it was a convention to use "r" for retval variables.

Re: A Guide to Naming Variables

#152

Post by jorams »

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 very much agree.

There are some cases where short variable names make sense. In the example the loop index is called "i", and that's good. It's good because it's just an index. The only reason it's there is because the looping construct isn't expressive enough for the desired loop semantics, so the short name means you don't have to care about it.

The use of "n" is also alright. It describes a number, for which "n" is a convention.

"c", on the other hand, is a horrible name. It's worse than "collection", because it's important and the scope is large enough that it's hard to skim for. "collection", however, is also bad. The variable doesn't just refer to a collection, it refers to a collection of integers. Why not call it "integers", or "numbers"?

I find conventions around this to really influence the readability of the average code in different programming languages. Lots of Haskell code can get away with short variables in small functions. Their scopes are small, their purpose is incredibly generic. C code often uses short variable names despite not being concise nor generic, making it unnecessarily hard to read. Common Lisp tends to use descriptive names. It's dynamically typed and contains little type information, and yet you always know what you're working with.

Re: A Guide to Naming Variables

#154

Post by jakub_g »

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

This pretty cool map shows distances between languages. English is Germanic and French is Romance but they are quite close.

https://elms.wordpress.com/2008/03/04/lexical-distance-among...

Re: A Guide to Naming Variables

#155

Post by jakub_g »

BinaryIdiot wrote: post #13
akkartik wrote: post #8

Off-topic, but blogspot links are a constant frustration for me on the phone. It's super easy for my fingers to swipe slightly left/right when scrolling and triggering blogspot's next/previous post navigation. I can even accidentally end up slightly scrolled horizontally and have no way to see the left side again. As a result I mostly ignore blogspot links. But this seems up my alley ( http://akkartik.name/post/reada…

I hadn't realized this was a blogspot thing. I had seen this multiple times and I completely agree. Almost every single time I go to keep scrolling, somehow slightly shift my finger to the right or left and BAM I'm in another article. Very frustrating and pretty counter intuitive for how we're used to the web working.

Blogspot is one of the most frustrating software out there that I interact with regularly (from HN mostly). Desktop version feels very slow and heavy, mobile version has this moronic feature of swiping to next/prev article, and countless other things that make UX really awkward.

Same with Google Groups and some other Google products. It's super weird, they sit on a pile of money, hire thousands of 'best of the best' and can't get some simple things right.

Re: A Guide to Naming Variables

#156

Post by bjterry »

dragonwriter wrote: post #125
logicallee wrote: post #99

Earlier quoted context omitted.

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.

AppleScript has an it keyword[0] that refers to the current application receiving commands. It's also made to resemble natural language in many other ways. From experience, this did not improve it's usability. It is often referred to as a read-only programming language because of that.

Wolfram includes the % keyword for the last result generated, IPython has something similar within their notebooks, R has the .Last.value keyword, Matlab has ans, and many other languages often used from a REPL probably have similar constructs.

0: https://developer.apple.com/library/mac/documentation/AppleS...

Re: A Guide to Naming Variables

#157

Post by nkurz »

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…

I realize it's not quite your point, but if you don't like repeating yourself, macros and "statement expressions" make it simple to extend languages to capture "it" to a tmp variable and then reuse it:

  #include 
  #include 

  #define dry(x, test, if_true, if_false)  ({              \
              typeof(x) _x = (x);                          \
              (_x test) ? if_true(_x) : if_false(_x);      \
          })

  #define abs(x) dry(x,

Re: A Guide to Naming Variables

#158

Post by detaro »

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

Beats me. So this is something that hasn't gotten any better for you over time? You should look at old school DSP code some time. :) Some of that is translating from variable names in mathematics papers. Also - for us old guys, you could take typing or you could take a math class, so many of us never really learned to type properly. So typing can be an actual consideration. Schools adapted to this later.

> You should look at old school DSP code some time. :) Some of that is translating from variable names in mathematics papers.

I feel that is sort of a valid exception. If it is common notation in the field you need to be familiar with anyways or you are implementing from a specific source, not using short names adds another layer of mental translation. If I'm implementing an algorithm from a paper I put an "implementation based on: " on top and try to match it as closely as possible. (DSP code probably doesn't do the latter, because performance, but where possible)

Re: A Guide to Naming Variables

#159

Post by JadeNB »

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…

> That actually does allow the same name to be used as a scalar, an array and a hash, but it's considered very bad practice.

Are you sure? I could have sworn that I'd seen this as actual style advice in the Camel book. A trip through `perldoc perlvar` (http://perldoc.perl.org/perlvar.html) shows that, at the very least, Perl itself doesn't abide by this convention; for example, we have the scalar `$ARGV`, the list `@ARGV`, and the filehandle `ARGV`.

Re: A Guide to Naming Variables

#160

Post by JadeNB »

lmm wrote: post #41
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'}`.

That feels like an ad-hoc reinvention of half a type system. If you want to keep track of your values' types (and you should), why not use a typed language?

As dragonwriter points out (https://news.ycombinator.com/item?id=11690914), Haskell best practice in naming includes things like `head (x:xs) = x`, and I think that one would not accuse this definition of involving an ad hoc reinvention of half a type system.
Post reply on HN