Beefy Boxes and Bandwidth Generously Provided by pair Networks
Pathologically Eclectic Rubbish Lister
 
PerlMonks  

Re: Perl Best Practices for naming variables

by Tanktalus (Canon)
on Aug 07, 2005 at 03:36 UTC ( #481603=note: print w/ replies, xml ) Need Help??


in reply to Perl Best Practices for naming variables

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.


Comment on Re: Perl Best Practices for naming variables
Download Code
Re^2: Perl Best Practices for naming variables
by creamygoodness (Curate) on Aug 07, 2005 at 05:12 UTC
    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

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

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

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://481603]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others drinking their drinks and smoking their pipes about the Monastery: (4)
As of 2014-09-03 06:38 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    My favorite cookbook is:










    Results (35 votes), past polls