I agree with tye - does look like golf :)

There comes a time when you have to balance this stuff out in a shared environment. For example, I've been optimising stuff perhaps too far:)

sub set_attr {
    # 0 self
    # 1 attr
    # 2 value
    $_[0]->{$_[1]} = $_[2];
}

sub get_attr {
    # 0 self
    # 1 attr
    $_[0]->{$_[1]}
}
[download]

What has come from this though is that I'm moving towards a more consistant @_ usage, and then passing the script through a source filter before publishing. IE, if the sub doesn't amend any arguments unexpectedly, I write code that shifts the args

sub set_attr {
    my $self  = shift;
    my $attr  = shift;
    my $value = shift;
    $self->{$attr} = $value;
}
[download]

but, before publishing, I run the code through a source filter to change it to:

sub addNums {
    # 0 self
    # 1 attr
    # 2 value
    $_[0]->{$_[1]} = $_[2];
}
[download]

sub capitalize {
    my ($word) = @_;
    $word = "\u$word";
    return $word;
}
[download]

I personally like using subs that tweak args direct:

sub capitalize {
    $_[0]="\u$_[0]";
}
[download]

But I find that most people feel more comfortable with:

$word = captitalize($word);
[download]

over

captitalize($word);
[download]

I'm sure there are some disadvantages to my approach, but as long as I keep it consistent, document the source filter and ensure I run tests before and after source filter is applied, I think I'm OK :)