I much prefer:

sub doSuff {
    my ($param1) = @_;
    ...
}
[download]

which then scales well to:

sub doSuff {
    my ($param1, $param2, $param3) = @_;
    ...
}
[download]

sub do_stuff1 {
    local $_ = shift;
    chomp;
    say;
}
[download]

sub do_stuff1 {
    ${ local *_ } = shift;
    chomp;
    say;
}
[download]

The latter handles the case where $_ is tied or otherwise magical. For example, $_ is magical if the parent does

for (..., $tied, ...) {
   ...
   do_stuff1(...);
   ...
}
[download]

for (..., substr($s, ...), ...) {
   ...
   do_stuff1(...);
   ...
}
[download]

You've ended up complicating things instead of simplifying them. It's best not to use $_ here.

Don't assign to a global variable without localising it. You just clobbered your parent's data.

Of course, the parent could protect its $_ my using a lexical variable. And so can do_stuff1. local $_ is in idiom I've had no need for the past 2 years.

sub do_stuff1 {
    my $_ = shift;
    chomp;
    say;
}
[download]

You also wrote:

or even safer:

sub do_stuff1 {
    local *_;
    $_ = shift;
    ...
}
[download]

Safer? You should test your code if you label it 'safe', or 'safer'. I guess you didn't realize that local *_; also gives you a new value for @_, so you no longer have access to the subs parameters?

You seem to imply it's not safer. Having a bug doesn't make it unsafe, it's makes it buggy.

You're also wrong that I don't realize @_ also gets affected. It just slipped through the cracks even though I remembered while I was composing the post. I usually use local * to do aliasing where this isn't a problem. I never localize $_ because it's suppose to be a shortcut but ends up longer.

Fixed.

As for my $_, that's new to the current version. Most people who come here don't use the latest version of Perl yet. I was going for a working solution, not a theoretical one. Thanks for mentioning it as an alternative, though.

Thanks for the guidance. I'm trying to digest it all.

Don't assign to a global variable without localising it. You just clobbered your parent's data.

I guess you mean like this:

use strict;
use warnings;
use 5.010;


sub do_stuff {
    foreach (1..5) {
        &dangerous($_);
        say "calculation in do_stuff(): ", $_ * 10;
        
    }
}

sub dangerous {
    $_ = shift;
    $_ *= 100;
    say "calculation in dangerous(): $_"
}

&do_stuff();

--output:--
calculation in dangerous(): 100
calculation in do_stuff(): 1000
calculation in dangerous(): 200
calculation in do_stuff(): 2000
calculation in dangerous(): 300
calculation in do_stuff(): 3000
calculation in dangerous(): 400
calculation in do_stuff(): 4000
calculation in dangerous(): 500
calculation in do_stuff(): 5000
[download]

By the way, I'm calling all user defined functions using the syntax &func() because the llama 5th ed. merely says that the & prevents name clashes with perl functions, therefore beginners should use the & until they become familiar with the names of perl functions. However, from the comments I gather there is more to it than that.

sub do_stuff1 {
    local $_ = shift;
    chomp;
    say;
}
[download]

I don't understand what local() does differently than my(). I read the docs, and I don't understand the difference.

or even safer:

sub do_stuff1 {
    ${ local *_ } = shift;
    chomp;
    say;
}

The latter handles the case where $_ is tied or otherwise magical.

What does that * notation do, and could you give some more details why that is safer than local $_? Maybe an example?

Thanks.

the & prevents name clashes with perl function

& is not a no-op. It causes prototypes to be ignored.

I don't understand what local() does differently than my().

my should be used whenever possible, but it's not possible to use my on package variables.

>perl -e"my $_"
Can't use global $_ in "my" at -e line 1, at end of line
Execution of -e aborted due to compilation errors.
[download]

$_ was made a legal name for a lexical in 5.10, and builtins will use the lexical $_ instead of the global $_ if there is one in scope, but not everyone is using 5.10 yet.

What does that * notation do

One reason my is preferred over local is that my creates a new variable, whereas local simply saves the variables current value (and restores it on scope exit). Any magic associated with the variable is unaffected by local.

You can localise the variable rather than its value by localising the glob that contains the variable. A glob is an associative array (like a hash) that contains the different type of variables ($name, @name, %name) associated with each name in the symbol table.

local *_ localises the whole glob, which means a new $_ will be created if one is needed.

sub do_stuff {

  my $foo = shift;
  my $bar = shift;

  ...
}
[download]

YuckStyle

Agreed.

This question brings to mind chromatic's recent blog post on The Act of Naming. Granted, his post is about subroutine names and why you might want to create technically-superfluous subs purely for the sake of being able to name sections of your code, but the reasoning seems applicable to variables as well: Creating a new (lexical) variable with a good name is cheap, safe, and easy - cheaper and easier than the contortions demonstrated by some of the other responses' attempts to keep assigning to $_ safe - and it also helps to convey what your code is actually intended to accomplish. So JFDI.

Note also that a statement like
    $_ = shift;
clobbers the contents of the  $_ default scalar. Because  $_ is global, this may cause Problems.

If you must use  $_ in this way, I would recommend the use of local within a statement or subroutine block:
    local $_ = shift;
or
    local ($_) = @_;
(but this still affects the value of  $_ as seen by any function called within that block after the point of local-ization!)

use strict;
use warnings;
use 5.010;

sub do_stuff1 {
    my $_ = shift @_;
    chomp $_;
    say;
}
[download]

Or even

use strict;
use warnings;
use 5.010;

sub do_stuff1 {
    given($_[0]) {
        chomp;
        say;
    }
}
[download]

Perl 6 - links to (nearly) everything that is Perl 6.

What, if anything, is gained by inserting a control statement (given) here in a context where it shouldn't ever affect the program flow? Are you just showing another way to do it or is there some subtlety to given which I have failed to grok?

there are some circumstances when using shift is preferable.

To what? What are you referring to?