Greetings my fellow monks,
I have recently been given the opportunity to review a software project that was written 3 or 4 years ago. The original author has since departed, but the project looks promising, and fortuitously (for me) it was written in Perl. I've been asked to look through it and document it so that we may be able to adapt it later.
The project is composed of a series of Perl scripts, using Bash scripts as wrappers to call them and pass data between them. The original author wrote several modules to handle various program tasks, all of which appear to be (to my supposed ability, such as it is) well-written though using Perl coding practices that seem older (e.g. using || die instead of or die after two-arg open statements).
What puzzles me is two modules that seem to handle configuration information, called ParseConfig and DataConfig, respectively. They do not read in a configuration file, but instead are primarily a series of package variables (with some subroutines thrown in as well) that are then used throughout all of the scripts, loaded via a use statement at the top, then referred to via their full package name (ParseConfig::somevariablename).
The two modules don't really feel like discrete entities -- almost as if they are catch-all modules instead of serving a well-defined function.
What I'm wondering is whether this is considered good Perl coding practice? I realize there are several ways to do things in Perl, but I'm trying to gauge whether this is something I would want to do or if there are better ways to do it -- and by it I mean share configuration data between several Perl scripts that do not run concurrently.
My review is not complete at this point, so take into account that I do not completely understand all the code yet, but I believe I've reviewed the majority of it.
In reply to Should you use a module to hold configuration items? by romandas
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |