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....
[download]

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
  .
  .
  .
);
[download]

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] );
}
[download]

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
                    .
                    .
                    )  ],
};
[download]

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

---

---

Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!

Titles consisting of a single word are discouraged, and in most cases are disallowed outright.

Read Where should I post X? if you're not absolutely sure you're posting in the right place.

Please read these before you post! —

• How do I compose an effective node title?
• How do I post a question effectively?
• Markup in the Monastery

Posts may use any of the Perl Monks Approved HTML tags:

a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr

You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)

	For:		Use:
	&		&
	<		&lt;
	>		&gt;
	[		&#91;
	]		&#93;

Link using PerlMonks shortcuts! What shortcuts can I use for linking?

See Writeup Formatting Tips and other pages linked from there for more info.