SirBones has asked for the wisdom of the Perl Monks concerning the following question:
Greetings all. I have a "best practices" question. What's the best way to deal with an annoying amount (from a source file maintenance point-of-view) of static text data?
I have a utility that does some data analysis on returned bit strings coming from various devices under test; one of the things it does is translate the bits that are "on" to their text meaning. For example, I might get a bit string from "device1" which looks like:
100110000000....
And so on, sometimes for several hundreds of bits. I've been keeping the meaning of the bits in various arrays:
@device1_status = qw ( Enabled Critical_fault Warning_fault Voltage_level_1_on Voltage_level_2_on . . . );
And when I walk through the bit string, it's simple enough to display the state of things:
foreach my $index (0 .. $#bits) { print "$device1_status[$index]\n" if ( $bits[$index] ); }
There are a number of possible devices, and each device has a different set of information specific to it. So sometimes I've been combining the labels into a hash of arrays:
%status = { 'dev1' => [ qw( enabled crit_fault warning_fault . . ) ], 'dev2' => [ qw( power_on OV_condition UV_condition phase_fault . . ) ], };
In any case, things have become very unwieldy in my source file. I have hundreds of lines taken up with these lists, and it will eventually number thousands. I know there must be a better way to organize this. I can think of some possibilities to separate the data and the code; I'm sure there are others:
- Stick all the big data structures in a separate Perl source file and do a require 'filename' to suck it in. Something like header file inclusion in C. Coming from a C background this is my first inclination.
- Put the labels in a flat text file and read them into an array when I need to do the translation. This will mean I will need separate text files for each device type (15 to 20). But it's simple and allows me to deal with the labels as a completely separate entity.
- Stick these structures into a separate module and use an access method to pull the info out as needed. My first feeling is that this is overkill for what I need, but it may be the most flexible approach; for example, it will allow other developers to use these mappings without reinventing the process. I don't really see that as a likely possibility now, but one never knows. It's hard to know if the extra effort in formulating the separate module(s) will be worth it.
- Throw the data into a database. Not practical due to portability and installation issues.
I'm curious as to how those folks with more experience in production level Perl apps would handle this.
Thanks,
Ken