in reply to warnings and strict -- The 2 Best Ways You Can Improve Your Programming

Another tip that will help you improve your code.

Stop using prototypes.

Yes, I am serious.

  • Comment on Re: warnings and strict -- The 2 Best Ways You Can Improve Your Programming

Replies are listed 'Best First'.
Re^2: warnings and strict -- The 2 Best Ways You Can Improve Your Programming
by liverpole (Monsignor) on Oct 05, 2005 at 11:56 UTC
    Can you explain why?
[reply]
      Without prototypes, the following two calls are equivalent: 
      sub ratio_change {...}
my @args = ($start_value, $start_total, $new_value, $new_total);
ratio_change @args;   # Same result as:
ratio_change $start_value, $start_total, $new_value, $new_total;

      [download]
      But with prototypes, they aren't: 
      sub ratio_change ($$$$) {...}
my @args = ($start_value, $start_total, $new_value, $new_total);
ratio_change @args;   # Eeks. Won't do what you think it does.
ratio_change $start_value, $start_total, $new_value, $new_total;

      [download]

      I don't shy away totally from using prototypes, but the only types I use are: 

      sub foo ();
sub foo ($);
sub foo (&@);
sub foo (\@@);
sub foo (\%@);

      [download]
      that is, I purely use prototypes to tell the parser how to parse things. I don't use it for argument checking (which is the typical use for '$$$$' style prototypes) as that get annoying fast - due to '$''s side effect of creating scalar context.
      Perl --((8:>*
[reply]
[d/l]
[select]
        I hadn't considered that argument, but it makes a lot of sense.  I can see where passing @list would now be prohibited because of a narrowing of definition of what passed parameters are legal.

        Since I still prefer to put subroutines at the end of the file, and call them with the simpler my $result = function $a, $b, $c; (or my $result = function @abc_list;), I will try to stick to using prototypes like:  sub ratio_change; where the argument list (and parens) are unspecified.

[reply]

In Section Meditations