Whew, I'm SO glad that's over. The 16000 line program no longer has any globals (at least no non-constant globals). Now I can move functions into different files and as long as I export the right functions everywhere, it should all just work.
Well, I did all that while being sick, and it didn't really contribute to my recovery, so I'm going to take it easy for a little while now.
I was just thinking about that particular antipattern today. I'm dealing with code like this:The 16000 line program no longer has any globals (at least no non-constant globals).
Now, obviously that's bad style, but why is it bad style? Then it struck me that it's a perversion of an old FORTRAN/C meme about peppering constant values around as bad style. Sure, it helps to put PI into a [constant] variable so that you localize the changes in exactly one place. Then, should your program ever be run in Indiana, it's much easier to reset the value of Pi to 3.my $DB = 'db';
my $PARAM = 'param';
$obj->{$DB}->{$PARAM} = $FOO;
But Perl is more smalltalkish in that respect, and it's more important to say what you really mean to say (when sending messages to objects, or indexing variables, or whatnot) rather than obscuring it through global variable references. So, constants used as part of a published API are good.
The more appropriate way to factor out globals and constant strings is when they are expected to vary, as in constants that are not part of an API:
Obviously, that's missing a $root_path type variable to handle the case where the program is moved to a host that hasmy $input = "/opt/foo/bar/input.txt";
my $output = "/opt/foo/baz/output.txt";
