Re^2: Perl Best Practices for naming variables

[creamygoodness]

in reply to Re: Perl Best Practices for naming variables
in thread Perl Best Practices for naming variables

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