Don’t Put Information in Two Places
While playing around with a Perl script to look up stock quotes, I
kept getting warning messages about uninitialized values, as well as
mising data in the results.
I eventually tracked it down to a bug in an old version of the
Finance::Quote
Perl module, specifically to these lines:
# Yahoo uses encodes the desired fields as 1-2 character strings
# in the URL. These are recorded below, along with their corresponding
# field names.
@FIELDS = qw/symbol name last time date net p_change volume bid ask
close open day_range year_range eps pe div_date div div_yield
cap ex_div avg_vol currency/;
@FIELD_ENCODING = qw/s n l1 d1 t1 c1 p2 v b a p o m w e r r1 d y j1 q a2 c4/;
Basically, to look up a stock price at
Yahoo! Finance,
you fetch a URL with a parameter that specifies the data you want to
retrieve: s for the ticker symbol (e.g., AMZN), n
for the company name (“Amazon.com, Inc.”), and so forth.
The @FIELDS array lists convenient programmer-readable names
for the values that can be retrieved, and @FIELD_ENCODING
lists the short strings that have to be sent as part of the URL.
At this point, you should be able to make an educated guess as to what
the problem is. Take a few moments to see if you can find it.
…
The problem is that @FIELDS and @FIELD_ENCODING
don’t list the data in the same order: “time” is the 4th
element of @FIELDS ($FIELDS[3]), but t1,
which is used to get the time of the last quote, is the 5th element of
@FIELD_ENCODING ($FIELD_ENCODING[4]). Likewise,
date is at the same position as t1.
More generally, this code has information in two different places,
which requires the programmer to remember to update it in both places
whenever a change is made. The code says “Here’s a list of names for
data. Here’s a list of strings to send to Yahoo!”, with the unstated
and unenforced assumption that “Oh, and these two lists are in
one-to-one correspondence with each other”.
Whenever you have this sort of relationship, it’s a good idea to
enforce it in the code. The obvious choice here would be a hash:
our %FIELD_MAP = ( symbol => s, name => n, last => l1, … )
Of course, it may turn out that there are perfectly good reasons for
using an array (e.g., perhaps the server expects the data fields to be
listed in a specific order). And in my case, I don’t particularly feel
like taking the time to rewrite the entire module to use a hash
instead of two arrays. But that’s okay; we can use an array that lists
the symbols and their names:
our @FIELD_MAP = ( [ symbol => s ], [ name => n ], [ last => l1 ], … )
We can then generate the @FIELDS and @FIELD_ENCODING
arrays from @FIELD_MAP, which allows us to use all of the old
code, while preserving both the order of the fields, and the
relationship between the URL string and the programmer-readable name:
our @FIELDS;
our @FIELD_ENCODING;
for my $datum (@FIELD_MAP)
{
push @FIELDS, $datum->[0];
push @FIELD_ENCODING, $datum->[1];
}
With only two pieces of data, it’s okay to use arrays inside
@FIELD_MAP. If we needed more than that, we should probably
use an array of hashes:
our @FIELD_MAP = (
{ sym_name => symbol,
url_string => s,
case_sensitive => 0,
},
{ sym_name => name,
url_string => n,
case_sensitive => 1,
},
{ sym_name => last,
url_string => l1,
case_sensitive => 0,
},
…
)
Over time, the amount of data stored this way may rise, and the cost
of generating useful data structures may grow too large to be done at
run-time. That’s okay: since programs can write other programs, all we
need is a utility that reads the programmer-friendly table, generates
the data structures that’ll be needed at run-time, and write those to
a separate module/header/include file. This utility can then be run at
build time, before installing the package. Or, if the data changes
over time, the utility can be run once a week (or whatever) to update
an existing installation.
The real moral of the story is that when you have a bunch of related
bits of information (the data field name and its URL string, above),
and you want to make a small change, it’s a pain to have to remember
to make the change in several places. It’s just begging for someone to
make a mistake.
Machines are good at anal-retentive manipulation of data. Let them do
the tedious, repetitive work for you.