This is one of the many benefits of keeping your code blocks (scope) as small as possible (one screen if possible), as it allows you to visually see what you're dealing with in regards to a variable.

To further, variable naming is important, as is attempting to write your subroutines so they only do one thing, as opposed to a whole bunch of things. This:

my $var->@;
[download]

... is far too much typing just for visual purposes (imho), and it adds unnecessary noise. It's just as easy to scope properly and name things appropriately:

my $cat;
[download]

That's singular, so I'd put money on the fact it's a scalar (unless it's an object, but if it's an object, it'll be being used much differently than a simple scalar so I digress).

my $cats;

# or

my $cat_list;
[download]

...or:

my $cat_map;
[download]

Both of those are extremely easy to identify to even a low-intermediate Perl hacker as an array reference in the former case, and a hash ref in the latter (perhaps the author has a hash of cat names to cat colours ;).

What's more, if there is confusion, in decently laid out code, one may have to scroll up only a tiny bit (if at all) to see where the variable is being declared/defined. If you have to search all over the code for where variables are defined, the scope for that variable is not small enough.

Even if you get the type wrong, with use strict; and use warnings; will always let you know the what/where of the problem.

So, in essence, I understand what you're desiring here, but good coding practices alleviate us from (for the most part) needing such visual cues.

Yeah. I completely agree with you with the idea of keeping subroutines or code blocks small. It is also my experience that this coding style (that you propose) has potential for eliminating most readability issues. So the naming issue can usually be circumvented using proper naming of variables and keeping the scope small. But it's also my experience that in some cases it would still be beneficial to have the option to further document the type of a reference variable.

What you're referring to in your last sentence is what some call "edge cases". These edge cases, where there may be ambiguity to the reader of the code is where your extremely brief comments should go. Code should document itself, but if you feel the reader may scratch their head:

...

my $x = thing_list(); # href
...
[download]

Of course, that's a pretty trivial example, but you get the point.

You wrote: "You should not be forced to used the more verbose form of the variable name."

Just in case there's a misunderstanding here, NOTHING in PBP is mandatory. Some of the recommendations do, in fact, reflect a concensus among some Perl programmers. Others are held up to criticism as 'one author's preferences.'

And here's another 'one person's opinion' about your observation that it "should it be entirely up to the user to ensure that he used the correct sigil."
Frankly, that idea is anathema to me; IMO, it's just another way to write code that you will have trouble deciphering sometime down the road, and that some future maintainer will almost certainly find problematic.

Yeah, I agree that the suggested reference syntax also could introduce new issues. For example consider function calls:

func( $var->@ )
[download]

Here it is of course possible that the programmer introduces a typo. First, assume he wrote @ when $var is a scalar (i.e. $var is not a reference). This typo will of course confuse a human reader. But the compiler would probably be quite happy. It would just ignore the optional postfix syntax (OPRDS). Hence, there will be no runtime issues with this typo either. Then consider a different typo. The user types @* when he rather meant to type @:

func( $var->@* )
[download]

Now, this is a more serious mistake. The compiler will assume that the array reference should be dereferenced. Hence, the function will receive $var->[0] instead of the reference $var, likely to cause some sort of runtime malfunction that may be difficult to debug.

I think, the programmer should have a choice to decide whether he finds it advantageous to include the suffix at given place or not.

Since we are dealing with references here then the programmer clearly does have that choice. viz:

#!/usr/bin/env perl 
use strict;
use warnings;

my $var = [1, 3, 5];
my $var_aref = $var;

print "var has values: @$var\n";
print "var_aref has values: @$var_aref\n";
[download]

So you, the programmer, can pick and choose which name to use at any point (if you so desire).

So you would prefer to introduce two reference variables? Sorry, I do not like this idea. I would prefer to keep the number of variables to a minimum. Introducing two variables just for the sake of solving a readability issue seems like a bad idea to me. What if one reference was changed later in the code? Then you must remember to update the other reference at the same place also. This clearly becomes a maintenance problem. And if you forget to update the other variable, there are potential for more confusion.

G'day hakonhagland,

"It sometimes bugs me that it is so difficult to write Perl code that is readable (easy to follow) when working with references."

About a dozen or so years ago, I supervised a number of junior programmers who also seemed to have this problem. I won't go into details beyond saying this caused no end of problems and time spent on debugging exceeded time spent coding.

I introduced a local coding standard, that required a prefix on all variable names whose values were references. There may have been some special cases, but these were the main ones:

• $rs_name : scalarref
• $ra_name : arrayref
• $rh_name : hashref
• $rc_name : coderef
• $rg_name : globref
• $ro_name : object reference

The concept was simple and mostly fixed the problem. Using the wrong operation on a variable was usually easy to identify (e.g. $ra_name->{...}, $rs_name->method(...), $rh_name->(...), and so on). Subsequent reading of the code, for maintenance or debugging, was made easier.

I should also point out another policy that the 'name' part had to be meaningful and, as far as possible, self-documenting. This typically meant that, if a wrong letter (identifying the reference type) was used, it would be picked up by strict (whose use was also mandatory).

While this was fine for that situation and environment, it doesn't really suit my personal style and I no longer use it: I much prefer to use the smallest possible, lexical scopes where these sort of problems generally don't occur. However, if you think this, or something like it, will help to improve your coding, perhaps give it a try and see if it works for you.

"Let's denote this new syntax by Optional Postfix Reference Declaration Syntax (OPRDS)."

I didn't like this idea at all. With postfix dereferencing, $var remains the variable and ->@* is an operation on that variable. With your OPRDS, $var->@ seems to be a separate variable and operation (in your OP); subsequently, in one of your responses, you use func( $var->@ ), where $var->@ now apparently represents the entire variable. You also seemed to get confused with "func( $var->@* ) ... the function will receive $var->[0] ...": in fact, the function will receive @$var.

You may have had typo(s) in that response, but I found myself scrolling back and forth to understand what was going on: the very problem you're attempting to avoid: "... scan source code nearby in order to determine ...".

>

    $rs_name : scalarref
    $ra_name : arrayref
    $rh_name : hashref
    $rc_name : coderef
    $rg_name : globref
    $ro_name : object reference
[download]

I'm using something very similar but without the redundant r in front, e.g $c_block .

Now I'm wondering why you use them... :)

Cheers Rolf
_{(addicted to the Perl Programming Language and ☆☆☆☆ :)
Je suis Charlie!}

Hello kcott!

Interesting to hear about your experience teaching students. I am sure the style you introduced might indeed help improve the situation you described. But once you have declared a variable with a prefix, it is no longer optional to remove the prefix. This is why I don't like the idea of a prefix that is part of the variable name. A prefix as a part of the sigil would seem like a better idea. Then it could be made optional.

For example, consider a function called with three references. A scalar reference, a hash reference, and a string reference;

sub func {
   my ( $rs_str, $hr_desktop_info, $ha_files ) = @_; 

  $$rs_string = update_string_ref();
  for ( keys %$hr_desktop_info ) {
     ...
     push @$ha_files, $file;
  }
  ....

}
[download]

I seems to me like the prefixes will introduce too much noise in the source code. In this case, it might be better if only the first line in the function documented the type of the reference, and then subsequent lines could omit the variable name prefix:

sub func {
   my ( $rs_str, $hr_desktop_info, $ha_files ) = @_; 

  $$str = update_string_ref();
  for ( keys %$desktop_info ) {
     ...
     push @$files, $file;
  }
  ....

}
[download]

Of course, the above code is not yet possible. And further it could not easily be made part of Perl in the future. But maybe a new type of prefix could be used, for example $>$, $>%, and $>@ ?

sub func {
   my ( $>$str, $>%desktop_info, $>@files ) = @_; 

  ....

}
[download]

On the other hand, I can see the clash here with the Perl special variable $> (The effective uid of this process). So this syntax might be difficult to implement.

Regarding the last point of your reply. Yes, I agree that if I call func( $var->@* ), the function will indeed receive @$var. But I assumed a function definition on the form

sub func {
  my ( $var ) = @_;
 
  ...

}
[download]

Now, the function would "receive" $var->[0] ( in the sense that $var in the function will be equal $var->[0] of the caller). But I think this (minor) issue of whether the function receives the whole array or only its first item is just a distraction from the main topic of the discussion. So I will not go further into the issue.

sub func {
   my ( $rs_str, $hr_desktop_info, $ha_files ) = @_; 

  $$str = update_string_ref();
  for ( keys %$desktop_info ) {
     ...
     push @$files, $file;
  }
  ....

}
[download]

I rather feel that $$str, %$desktop_info and @$files make it pretty clear, not only that your dealing with references, but also what type of references they are.

If you're having problems reading that, I suggest you do what ++stevieb has already alluded to and put the prefixes in a comment. Something like:

    my ($str, $desktop_info, $files) = @_; # rs, rh, ra
[download]

Update (minor typo fix): s{deck}{desk} in ..., %$decktop_info and ....

— Ken

There's a new feature that appeared in "developer release 5.25.3". It's mentioned in "(5.25.3) perldelta: Declaring a reference to a variable". Details are in "(5.25.3) perlref: Declaring a Reference to a Variable". The text of that last link starts with "Beginning in v5.26.0, ...": so, if you don't want to install a developer version (the latest is 5.25.9), you probably won't have long to wait for a stable one.

I think this is the sort of thing you were after:

#!/usr/bin/env perl

use 5.025003;
use strict;
use warnings;

no warnings 'experimental::refaliasing';
use experimental qw{refaliasing declared_refs};
use feature 'declared_refs';

{
    my $str  = \'string';
    my $list = [qw{a b c}];
    my $map  = {x => 24, y => 25, z => 26};

    func($str, $list, $map);
}

sub func {
    my (\$string, \@array, \%hash) = @_;

    say $string;
    say "@array";
    say "$_ => $hash{$_}" for sort keys %hash;

    return;
}
[download]

Sample run:

$ perl -v | head -2 | tail -1
This is perl 5, version 25, subversion 9 (v5.25.9) built for darwin-th
+read-multi-2level
$ pm_1179933_test_exp_declared_refs.pl
string
a b c
x => 24
y => 25
z => 26
[download]

Important: Do note that this feature is experimental; subject to change; and, as such, not suitable for production code.

As someone who prefers camelCase I use a more succinct convention.

my $rsSomeValue = \ do { my $val = 42 };   # scalar ref
my $raCats = [ qw{ Tiddles Desmo Felix } ] # array ref
my $rhAges = { John => 23, Bill => 35 };   # hash ref
my $rcDoIt = sub { return $_[ 0 ] * 3 };   # code ref
my $rxPat = qr{abc};                       # regexp ref
my $roObj = Some::Pkg->new()               # object ref
[download]

If I see something matching m{\$r[sahcxo][A-Z]} I know I'm dealing with a reference.

Hello johngg.

Yes, it is shorter, but is it more readable? This also extends to the discussion of whether to use snake_case or camelCase. In my opinion camelCase is more succint (easier to type), whereas snake_case is more readable (but more difficult to type).

I also once used camelCase, so I can understand your choice. My main objection though is that the prefix syntax (that you propose) is not optional. See also comment to kcott for more information.

Camel case makes my skin crawl. Hate it. Give me underscores or give me death.

$PM = "Perl Monk's";
$MCF = "Most Clueless Friar Abbot Bishop Pontiff Deacon Curate";
$nysus = $PM . ' ' . $MCF;
Click here if you love Perl Monks

I guess it's all a bit subjective. I don't dislike underscores and can happily use them if mandated but camelCase keeps long descriptive variable names shorter which is why I prefer it.

Cheers,

JohnGG

With all that was said here on this thread, I want to say that while learning, knowing what is what is definitely important. Knowing this thread is so relevant still, I thought I'd share an example of where I'm learning something (converting Perl variables to C), that indeed, it's useful to be able to identify your vars so one understands what's happening. See this thread. That naming convention won't last but a day, but it can be useful in code while still trying to grasp what's going on.