The point I was trying to make "I think perl's shortcuts can get in the way of writing maintainable code sometimes", wasn't based on personal experience as I caveated. When I explain a piece of code to someone who doesn't know perl that well, regardless of how well they program in other languages, I find myself constantly having to explain what is implied but not said. When I explain my own code to someone who does understand perl, they still often complain that my terseness is too much (diotalevi for instance).
To be clear, I was advocating avoiding shift entirely.
I find the bar() sub faster to update with less mistakes. I know the mistake is easily found and corrected with warnings and strictures but it helps me to avoid them in the first place.sub foo { my $this = shift; } sub foo { my ($this, $that) = @_; } sub bar { my ($this) = @_; } sub bar { my ($this, $that) = @_; }
I guess working around a bunch of Java programmers who can't understand my code has tainted me. Update: I don't know if I defended my position that well. As I said, I don't have any real world experience with production code. My limited non-professional experience tells me terse implicit code requires another person more time to understand than it would take me to write it explicitly the first time.
Cheers - L~R
In reply to Re^3: Practical example of "Is Perl code maintainable"
by Limbic~Region
in thread Practical example of "Is Perl code maintainable"
by eyepopslikeamosquito
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |