What I'm wondering is whether this is considered good Perl coding practice?Note that you're asking two questions. One question is "do I store configuration data in config files, or as Perl code". The second is "do I make this data available via fully qualified variable names".
Let's answer the second question first. It's not my first choice. I prefer having a single module provides configuration settings that extend the scope of a single file, but than I rather import variables (or constant subs) into my name space. Or sometimes a hash with all the settings (like Config.pm). For large projects, I may group the settings, allowing them to be imported by tags (Fcntl.pm does this as well).
For the first question, it depends. For some settings, it makes more sense to store them outside of the code - for instance, for settings that may be vary from machine to machine (you may have a webserver farm, not all of them connecting to the same physical database - you may want to store connection settings in a config file, whose content varies from machine to machine. Or you have a user applications, allowing each user their own settings - think the preferences file of your browser). Other settings you really do not want to be configurable in a separate file. Think for instance positions in a bitfield. Or the value of π. Or settings that are calculated, or derived from others.
In reply to Re: Should you use a module to hold configuration items?
by JavaFan
in thread Should you use a module to hold configuration items?
by romandas
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |