Live data from Hacker News

A Guide to Naming Variables

a-nickels-worth.blogspot.com

161–170 of 175 posts

Re: A Guide to Naming Variables

#161
There is always this alternative: don't have any variables to name!

  (defun print-first-n-pos (n seq)
    [(opip (take n)
           (keep-if [orf zerop plusp])
           (progn
             (mapdo (op put-string `@1 `) @1)
             (put-line)
             @1)
           (- n (length @1)))
     seq])


  $ txr -i first-n-pos.tl
  1> (print-first-n-pos 4 '(-1 2 3 4 5 6))
  2 3 4 
  1
  2> (print-first-n-pos 5 '(-1 -2 3 4 -5 6))
  3 4 
  3
Well, @1 is technically a variable. :)

Re: A Guide to Naming Variables

#162
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)?

actually i for "index" ('ix'->'index x'), not "integer"

Re: A Guide to Naming Variables

#163
post #159
post #39

Earlier quoted context omitted.

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…

From Modern Perl, 2014 Edition[1]

    Sigils allow you to separate variables into different namespaces. It's
    possible–though confusing–to declare multiple variables of the same name
    with different types:
    
        my ($bad_name, @bad_name, %bad_name);
    
    Though Perl won't get confused, people reading this code will.
There are plenty of things that are shown as possible in the Perl docs, and only slightly less things recognized as generally a bad idea in most circumstances. Instead of Python's one way to do it, there's really more 1 to 3 accepted, idiomatic ways to do it, and another 2-3 that are considered "situationally acceptable" (those odd cases where it actually makes things more readable, etc). There's often a couple ways that are deemed generally just a bad idea, or at a minimum, still waiting for that special case where they can shine. ;)

1: http://onyxneon.com/books/modern_perl/modern_perl_a4.pdf (But you should buy it if you are interested, chromatic knows what he's talking about).

Re: A Guide to Naming Variables

#164

Earlier quoted context omitted.

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.

Problem with that (for me) is that I use that for radius all the time, as in r * sin( a * t )

Re: A Guide to Naming Variables

#165

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…

> Maintenance and working on other people's code is now solved if it's the same code you would write yourself.

Easier perhaps, but certainly not solved. I often have trouble maintaining and working on code I wrote.

Re: A Guide to Naming Variables

#166

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…

Agreed with you. Perhaps if you're using temp or tmp, something could be done better, but I see no harm in using the others. If you're counting things, a variable named "count" sound perfectly reasonable to me.

Came here to say this. I bumped my head hard on this part of the text - the whole point of using a cliche is that it's immediately understandable. When I come across an incrementing loop that doesn't use a cliche variable like "count" or a function that doesn't return "return" it increases my mental tax. The nice thing about using a variable like "count" or "return" throughout your function is it's immediately intuitive what's going to happen with this variable.

Re: A Guide to Naming Variables

#167
post #159

Earlier quoted context omitted.

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

From Modern Perl, 2014 Edition[1] Sigils allow you to separate variables into different namespaces. It's possible–though confusing–to declare multiple variables of the same name with different types: my ($bad_name, @bad_name, %bad_name); Though Perl won't get confused, people reading this code will. There are plenty of things that are shown as possible in the Perl docs, and only slightly less things recognized as gen…

> There are plenty of things that are shown as possible in the Perl docs, and only slightly less things recognized as generally a bad idea in most circumstances.

Notice, though, that I'm not talking about the Perl docs merely noting that it's possible—I agree that the spirit of the docs is more "look what I can do!" than "look what you should do." I'm talking about what Perl itself does (with the use of `$ARGV`, `@ARGV`, and `ARGV`—although maybe `$_` and `@_` is a better illustration).

chromatic is an excellent programmer, and I certainly respect his voice on Perl over, say, mine, but I feel that he is rather strict, and I do not take his opinions as necessarily representing those of the larger Perl community, as exemplified, among many others, by Wall, tchrist, Conway, and/or merlin.

Re: A Guide to Naming Variables

#168
post #167

Earlier quoted context omitted.

From Modern Perl, 2014 Edition[1] Sigils allow you to separate variables into different namespaces. It's possible–though confusing–to declare multiple variables of the same name with different types: my ($bad_name, @bad_name, %bad_name); Though Perl won't get confused, people reading this code will. There are plenty of things that are shown as possible in the Perl docs, and only slightly less things recognized as gen…

> There are plenty of things that are shown as possible in the Perl docs, and only slightly less things recognized as generally a bad idea in most circumstances. Notice, though, that I'm not talking about the Perl docs merely noting that it's possible —I agree that the spirit of the docs is more "look what I can do!" than "look what you should do." I'm talking about what Perl itself does (with the use of `$ARGV`, `@A…

> I'm talking about what Perl itself does (with the use of `$ARGV`, `@ARGV`, and `ARGV`

I suspect that's a combination of Perl's influence from awk (@ARGV), wanting something easier than awk's ARGIND for the current index in ARGV, and wanting to try out some of these new features Perl had in the beginning. I also suspect that things like this may be on the list of things Larry regrets about early Perl choices. I believe he's on record as saying he regrets the choice of sigil variance for array/hash and array/hash access (@foo as $foo[0] instead of something like @foo[0]). He's got good reasoning for why he chose what he did (based on language, it makes sense), but it's just overly confusing for beginners.

> although maybe `$_` and `@_` is a better illustration

I'm willing to give them a special case, because they are unique, as variables go (well, less so than they should be given Perl's many magic variables, but I think you understand my point). That said, I don't think many Perl programmers would argue that @_ was a better choice than @ARGUMENTS, or something equivalent.

As for assuming the docs in general reflect the current best practices.. I'll just note that the perlopentut man page still uses bare filehandles in the majority of its examples, and to my mind that was decided long ago as a community to be downplayed in favor of lexical filehandles (but for more practical reasons than what we are discussing, bare filehandles are globally scoped).

> chromatic is an excellent programmer, and I certainly respect his voice on Perl over, say, mine, but I feel that he is rather strict

I'm not going to argue with that. I respect chromatic's opinions on style and Perl 5, but I'm not entirely sure he's capable of being entirely objective with Perl 6 yet (which I can understand). He is rather adamant about what he believes are better approaches to a topic.

> I do not take his opinions as necessarily representing those of the larger Perl community, as exemplified, among many others, by Wall, tchrist, Conway, and/or merlin.

Fair enough, but I wasn't sourcing that believe from Modern Perl, just pointing to it as evidence. To be honest, I haven't read Modern Perl (but I've read a lot of chromatic's writing from his blog back in the day when he was writing it), I just assumed it might have something to back up my view, so looked in it. My view on variable naming here is perfectly capable of being more my own opinion that the community, and I was projecting. It's hard to know in Perl unless there's a discussion (and sometimes even after that), as what's acceptable is often a mostly overlapping set of best practices from person to person, but rarely are the sets of preferences entirely equivalent. :)

That said, Conway's Perl Best Practices suggests "Name arrays in the plural and hashes in the singular." It doesn't address our topic directly, but I don't know where my copy went (I sourced that from one of the many two page reference PDFs for PBP) and I don't recall the reasoning he used for that one. I wouldn't fault you for disagreeing with him though, I've shifted my view on some of his suggestions over the year towards or away from his suggestions (notably not using parens on built-ins, but I'm more in-line with his thinking now than I was a decade ago).

Re: A Guide to Naming Variables

#169
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 me it's not how many lines there are in the function, but how many lines of scope the single-character variable lives. If it lives for 2-3 lines in a 12 line function, the dude abides the name.

Re: A Guide to Naming Variables

#170
post #167

Earlier quoted context omitted.

> There are plenty of things that are shown as possible in the Perl docs, and only slightly less things recognized as generally a bad idea in most circumstances. Notice, though, that I'm not talking about the Perl docs merely noting that it's possible —I agree that the spirit of the docs is more "look what I can do!" than "look what you should do." I'm talking about what Perl itself does (with the use of `$ARGV`, `@A…

> I'm talking about what Perl itself does (with the use of `$ARGV`, `@ARGV`, and `ARGV` I suspect that's a combination of Perl's influence from awk (@ARGV), wanting something easier than awk's ARGIND for the current index in ARGV, and wanting to try out some of these new features Perl had in the beginning. I also suspect that things like this may be on the list of things Larry regrets about early Perl choices. I beli…

Your points are all very good ones, and I appreciate your civil engagement with my argument—especially since all I've really done is quibble with your sources rather than produce any of my own (because I am in the same boat as you, being away from my Perl books). In fact, even if I could find quotations from eminent Perl programmers to support my position, the very nature of TIMTOWTDI would mean that my argument wouldn't represent the entirety, or even the majority of, the Perl community.
Post reply on HN