Re: Improve readability of Perl code. Naming reference variables.

[kcott]

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

[LanX]

>

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

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... :)

[hakonhagland]

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;
  }
  ....

}

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;
  }
  ....

}

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 ) = @_; 

  ....

}

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 ) = @_;
 
  ...

}

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.

[kcott]

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

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

}

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

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