Beefy Boxes and Bandwidth Generously Provided by pair Networks
Just another Perl shrine

Re: Perl Best Practices for naming variables

by chester (Hermit)
on Aug 06, 2005 at 22:39 UTC ( #481563=note: print w/ replies, xml ) Need Help??

in reply to Perl Best Practices for naming variables

Even the distinction between $comment and $comments isn't very great, in my opinion. For reading code more than writing, that is. If using singular/plural to make the distinction like that, I'd probably make some further distinction as well, if two variable names were that similar. If all else failed maybe $a_comment (ugh, that's ugly) or $single_comment or $final_comment or $comment_about_dogs or who knows what.

So far as _ref, I guess the deciding factor is whether it's more important to easily tell references from non-references, or arrays/hashes from scalars.

If you see $var_ref, then first you can immediately tell "It's a reference!" and then you'll have determine whether it's an array ref, hash ref, or scalar ref or whatever.

On the other hand if you're using plural/singular to make the distinction, then if you see $items you first know "It's an array!", and then you're faced with figuring out (or remembering) if it's an array item or array reference. $items[1] vs. $items->[1] aren't so easy to distinguish at a glance, especially if it's buried in the middle of a bunch of other line noise.

I can easily see the argument going either way. I'd personally lean towards using _ref because I find myself mixing up hashrefs with hashes pretty often while writing code. I believe Damian mentions in the book that it's helpful if typing _ref-> as a unit becomes a habit, and it seems to work for me.

Comment on Re: Perl Best Practices for naming variables
Select or Download Code
Re^2: Perl Best Practices for naming variables
by creamygoodness (Curate) on Aug 07, 2005 at 00:36 UTC
    # before Damian's book I'd have used EOREPLY my $reply_to_chester = <<'END_REPLY_TO_CHESTER';

    Exactly right, that's what Damian recommends. There's obviously someone besides him who's made it work.

    I suppose I've just solved the problem he's looking to address by never using identical identifiers for different purposes. What's the advantage to me for adding those extra four characters? Now I can use %option, @option, $option, and &option in the same scope and, uh, not get them mixed up? ;) On the flip side, what's the penalty for typing$items[1] when you meant $items->[1]? No more than a missing semi-colon, or other simple syntax error. Unless your program takes a long time to compile, no big deal: run, tweak, run, tweak...

    I might not find this constraint so onerous if I hadn't produced a lot of code that goes up to 78 characters.

    ... (time passes while Marvin peruses book) ...

    It looks like the answer is, for Perl 5.8.1 onwards, the Data::Alias module. The main situation where I'd need _ref is when pulling elements out of a large and complex object for manipulation in a method. Here's what I've been doing:

    sub do_stuff { my $self = shift; my $items = $self->{items}; # Bear with me and assume I'll need $items again... for my $item (@$items) { # etc...
    With the Data::Alias module, I can do this instead:
    sub do_stuff { my $self = shift; alias my @items = @{ $self->{items} }; for my $item (@items) { # etc...

    That's probably faster. It's sure cleaner. I like. And as a bonus, now when I use _ref, it will imply something useful -- like, "this is a giant array and I want to pass it by reference".

    Tasty spinach, yo,

    Marvin Humphrey
    Rectangular Research


Log In?

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

How do I use this? | Other CB clients
Other Users?
Others browsing the Monastery: (11)
As of 2014-09-02 10:42 GMT
Find Nodes?
    Voting Booth?

    My favorite cookbook is:

    Results (21 votes), past polls