I agree with most of the above comments, and in particular,
I would also stress how important it is to have "constant"
data outside of your function.
Additionally, eliminating duplication is also a priority,
though not at the expense of needless complexity. In this
case, @SYS is really the same as keys %POvars,
so there is no need for this extra definition.
Further along those lines, I would restructure your
definition something like:
my @POvars_common = qw[ ppo userid email ];
my %POvars = (
'GRP' => [@POvars_common, 'gwpo', 'gwdomain'],
'JAG' => [@POvars_common, 'jagexcept'],
'CIS' => [@POvars_common],
'MST' => [@POvars_common],
'GCG' => [@POvars_common]
);
Although this doesn't seem like a big deal, removal of
duplication can help with:
- Accidental transposition errors, such as one of your
entries having 'emall' instead of 'email', which is hard
to spot amidst many similar lines. Using Perl with the
'-w' option, and use strict will spot errors
in your variable names, but not your string constants,
unless these happen to generate errors as well.
- Errors when changing the structure on a global scale,
which requires modifications to every single entry in this
case. This usually happens to every program, so plan for it
in advance.
- Synchronization errors between needlessly linked data
structures, such as @SYS and %POvars,
where one has an entry which the other does not.
| [reply]
[d/l]
[select] |
| [reply] |