A Guide to Naming Variables • Hacker News Board

Re: A Guide to Naming Variables

#171

Post by chromatic » Sat, May 14, 2016, 8:16 PM UTC

JadeNB wrote: post #167

kbenson wrote: post #163

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…

Keep in mind two things, with regard to Modern Perl:

* it's a book for novice programmers, people with perhaps six months of practical programming experience

* it's a book for novice Perl programmers, people who don't have voluminous experience with the language itself

I believe programming is an exercise in making tradeoffs based on incomplete information. You can't teach the kind of good judgment that's based on experience, but I can try, at least, to guide novices away from some of the traps that they're likely to fall into. The subtleties of separate namespaces are difficult enough to learn on your own that it seemed worthwhile to advise strongly against name cognates.

I don't expect that Larry, Tom, Damian, or Randal follow my advice. I don't even follow it in my own code many times. It's not advice for experts.

Re: A Guide to Naming Variables

#172

Post by blastrat » Sat, May 14, 2016, 8:22 PM UTC

tome wrote: post #165

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…

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

I'm not saying it's anywhere near perfect :) but can you see that if a naming system works so well that two people would quickly write the same code, that reading that code could conceivably be easier too? That's the claim.

Re: A Guide to Naming Variables

#173

Post by dwc » Sat, May 14, 2016, 8:25 PM UTC

Grue3 wrote: post #76

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

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

Ok, for those cases I have to agree with you. :)

Re: A Guide to Naming Variables

#174

Post by JadeNB » Sat, May 14, 2016, 8:43 PM UTC

chromatic wrote: post #171

JadeNB wrote: 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…

Keep in mind two things, with regard to Modern Perl : * it's a book for novice programmers, people with perhaps six months of practical programming experience * it's a book for novice Perl programmers, people who don't have voluminous experience with the language itself I believe programming is an exercise in making tradeoffs based on incomplete information. You can't teach the kind of good judgment that's based on e…

I appreciate this measured response, but want to make very explicit that I did not mean to criticise you or your advice, much less deny its value to the novice programmer; I certainly apologise if I did so unintentionally.

I always enjoy your writings on Perl, even if I sometimes disagree with specific opinion-based recommendations (as is, almost by definition, the prerogative of Perl programmers), and I hope that I didn't seem to be knocking you or them. I was not even disagreeing with this particular advice, just saying that it didn't necessarily establish the attitude of the broader Perl community on punning in variable names. (There always will be code golfers who will value cleverness over maintainability—and there should be; without them we would never have such gems as `[$a => $b]->[$b <= $a]` for `min($a, $b)`.)

Re: A Guide to Naming Variables

#175

Post by kbenson » Sat, May 14, 2016, 11:27 PM UTC

JadeNB wrote: post #170

kbenson wrote: post #168

Earlier quoted context omitted.

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

Sure! In the end, there's not much that could really be said to definitively settle this besides a survey of a sizable amount of the Perl community. All we're left with is what our own preference is, and what's stuck out to us from books, blog posts, comments and meetings, which is very prone to confirmation bias. In the end, even if the consensus is it's better not done, I don't doubt it would be on the lighter side of ways you could disappoint coworkers. It's only really confusing to the Perl amateur. That's sort of what I meant by coworkers and dirty looks, rather than suggest your coworker will forcibly change your code for their own sanity. ;)