Re: Perl Best Practices for naming variables

[Tanktalus]

The _ref suffix looks like a Damianised version of Hungarian Notation. Not the popular version, but the original. The purpose seems to be to help ensure that just by looking at the code, you can tell if it's correct or not. For example, if you have adhered to this naming convention, you could tell at a glance which of the following are correct, and which would result in a runtime error, should that codepath be excersised:

  $comments[0]       = 'foo';  # 1
  $comments_ref[0]   = 'foo';  # 2
  $comments->[0]     = 'foo';  # 3
  $comments_ref->[0] = 'foo';  # 4

Obviously, then, 1 and 4 are good, while 2 and 3 will result in runtime errors. And that's without seeing any other code. This means you can look at each line in isolation and be able to intuitively understand its correctness, or lack thereof. That's goodness.

Now, in the original Hungarian notation, these are to be prefixes. But where you put the notation is less relevant than having a consistant, well-defined notation that translates runtime errors into things that are obvious from a simple code-review.

[creamygoodness]

Haha, great etymological humor in that Wikipedia link.

A point of clarification... this fails at compile-time:

$comments_ref[0]   = 'foo';  # 2

... while this fails at runtime (assuming that $comments doesn't contain a ref, as implied by the lack of HungDamian suffix):

$comments->[0]     = 'foo';  # 3

I hadn't addressed the situation where a spurious dereferencing operator causes problems, but yes, now that I think about it, I've done that every once in a while. Depending on how rarely the code branch containing the bogus arrow gets accessed, that might produce an unpleasant surprise at an inopportune moment.

Fortunately, thanks to Data::Alias, I can have my spinach and eat it too. I'm persuaded. I'll start using _ref.

But those hash names are going to stay plural for now.

Cheers,

--
Marvin Humphrey
Rectangular Research
http://www.rectangular.com

[Tanktalus]

$ perl -c -e ' my $c_ref; $c_ref[0] = "foo"'
-e syntax OK

The moral is that you should always use warnings and strict. But, even if you don't (or can't), $c_ref[0] is still obviously wrong if you're looking at code following the HungDamian naming convention.

(Personally, I think we should come up with a better name than that - Damian may like this one too much. And his publicist may not ;-})

PS - I'm not attempting to convert anyone to this style of naming. I don't use it myself, and I'm not sure I'm going to start, either. Someone asked why Damian would have suggested this, and I answered. Personally, if I were to start, it'd be using an 'r' prefix rather than a '_ref' suffix.

[ff]

I smiled when I came upon the '_ref' suggestion, recognizing it as a practice I already followed, sort of. Like you, I don't need the 'ef' part of that tag chewing up valuable line space and/or adding clutter. However, rather than just stopping at '_r', I DO like inserting an extra character to indicate the kind of reference I expect to be referencing. As in:

    _ar for array ref
    _hr for hash ref
    _xr for code ref
    _sr for scalar ref

The program I'm writing has grown to be many lines and I prefer as much clarity as possible when I reread sections of it. If helps document my intentions which helps when refactoring. And with all the subroutines I end up inventing, it makes for a clear set of expectations of what variables should be passed to the subroutine without having to use prototypes.

    sub foo {
        my (
            $camels_ar,
            $votes_hr,
            $count_mechanism_xr,
        ) = @_;

Frankly, I wish more books that teach Perl would use this approach because as the learner, it's hard enough trying to understand some new idea without having to fight through the additional ambiguity of "now what's in this variable and why is it written up that way?"