in reply to Creating Variables Just to Pass into Subroutine?
refactoring inherited code can be scary, unless you have a good set of tests for all the use cases the code needs to handle. Think of it as a safety net before you start. Also, a version control system would be useful in case of unintentional destructive changes...
So this should be the foundation to build on and the first step.
Once you have that, I would start refactoring with the help of Damian Conways' book 'Perl best practices' and the Perl-Critic tool. Keep the amount of changes small and focused, and retest often. Always before checking into version control.
Regarding your code snippet: assigning one variable to another one at least has the benefit of having more meaningful variable names (which makes it more user friendly, but is a bit redundant). Why not use good names in the first place?
Passing subroutine parameters in a hash, where the keys name the parameters, can also yield readable code, since the names are part of the subroutine interface then.
I hope this helps a bit.
|
|---|
| Replies are listed 'Best First'. | |
|---|---|
|
Re^2: Creating Variables Just to Pass into Subroutine?
by mdskrzypczyk (Novice) on Jul 22, 2015 at 13:38 UTC | |
by SuicideJunkie (Vicar) on Jul 22, 2015 at 14:54 UTC |