Re: shift vs @

I can think of one reason not yet mentioned: Multi-line shift makes patches more readable. Imagine you have:

sub blah {
    my $foo = shift;
    my $bar = shift;
}
[download]

If I want to add another argument (maybe at this point I should consider hash-based arguments as above, but let's assume I can't, maybe for backwards compatibility), I might rewrite this as:

sub blah {
    my $foo = shift;
    my $bar = shift;
    my $baz = shift;
}
[download]

The patch to add this argument only contains one additional line with the new argument, making the code easier for people reviewing changes in your version control system or reviewing patches before committing them.

If you change my ($foo, $bar) = @_; to my ($foo, $bar, $baz) = @_; traditional patch/diff output shows one line removed and one added which makes it a little less clear that the change does nothing other than add one new argument.

Comment on Re: shift vs @_ Select or Download Code

Replies are listed 'Best First'.
Re^2: shift vs @_ by Argel (Prior) on Oct 02, 2006 at 20:26 UTC
I'm not going to claim this is better but it does allow you to meet your change management goals while still using the my()=@_ form. `sub blah { my( $foo, $bar, $baz, ) = @_; }` [download]	[reply] [d/l]
Re^3: shift vs @_ by Argel (Prior) on Oct 02, 2006 at 20:39 UTC
Actually, I think I will claim it is better. In theory it should be easier to notice changes since there is less clutter -- no leading "my" and no trailing "= shift" that someone eyeballing the code has to filter out so the variables themselves should stand out better.	[reply]
Re^4: shift vs @_ by tomhukins (Curate) on Oct 02, 2006 at 20:44 UTC
Perhaps, but consider the starting point of one argument: `my( $foo, ) = @_;` [download] compared to: `my $foo = shift;` [download] I use the shift approach because it gives me a clean starting point and lets me extend my methods (or subroutines) easily. Having said that, I try to avoid extending public methods and prefer to create new methods when appropriate. But perhaps I'm drifting away from the original question a little..	[reply] [d/l] [select]
Re^2: shift vs @_ by GrandFather (Saint) on Oct 02, 2006 at 21:25 UTC
That depends on the diff tool you use. TortoiseSVN's diff shows changes within a line for example, so the extra verbiage associated with the shift is not required. Besides, generally the number of times you have to check deltas to solve a problem are many fewer than the number of times you look at the code in the process of writing or using it. An idiom that provides clarity in writing and use is more important than occasional merge or delta issues. Using the list assignment form makes it easier to match the parameter list in the call with the required parameters - the assignment list self documents the required parameters (especially if good names are used). DWIM is Perl's answer to Gödel	[reply]


Perl Monk, Perl Meditation
	PerlMonks

Re: shift vs @_