Re^4: Perl 'grammar'

Good point. You lose the uc bit, but its awfully tight.

I think I was reacting more to the parameter unpacking. The sub is handed a compound, and the parameter is stored and then broken apart. I tend to think of that breaking as part of the unpacking process, so in essence get two params passed to the sub in a particular format, hence my "first" line produces those two variables.

It all comes down to chasing errors, I suppose. I've gotten the habit of putting in a print (or warn) at subroutine entry with the parameters passed controlled by a debug variable. With the one-liner, you can't really do that. But then again, its so bloody simple, perhaps its not necessary.

--woody

Comment on Re^4: Perl 'grammar'

Replies are listed 'Best First'.
Re^5: Perl 'grammar' by gamache (Friar) on Jan 10, 2008 at 18:10 UTC
I tend to write my subroutines in three parts: first, a preamble where I throw the passed args into named variables; second, all the guts; and last, the return value. I find it helps with extensibility (but only barely).	[reply]
Re^6: Perl 'grammar' by WoodyWeaver (Monk) on Jan 10, 2008 at 18:42 UTC
Me too. That must mean its a "best practice". :-) However, when unpacking the passed args into named variables, there is often some cleanup that needs to be done, such as assigning defaults for unpassed values, sanitizing, etc. I would tend to classify breaking "last, first" into "last", "first" as part of that 'throw into named variables' phase rather than the 'guts' phase, where you are making meaningful changes or performing analysis. I'm kinda weak about the last part, though. Sometimes I tend to return early, if I can determine what I'm going to send back from the subroutine. Screws up debugging, though. Use of your three part strategy means that one can put a print just before the final return, and gain insight into what the sub is really doing.	[reply]