This seems like an organizational problem. Maybe:

• Supply each person or group that is responsible for maintaining a 'sub' file or files a custom Perl script for checking the file(s) for which they are responsible. The script begins with
      use strict;
      use warnings FATAL => 'all';
      use vars qw($all $needed $global $variables);
  (some of the fake 'globals' may need to be initialized) and continues with a
      require sub_file_foo.whatever;
  for each sub-file in question. It may be necessary for some sort of fake hash to be built from all the sub-hash-thingies (I don't have a good idea of the organization of all the code in this crazy system) for final verification. Finally, the script prints
      print "sub-file(s) look ok.";
  and exits.
• Establish a 'release date' or 'release number' for each production build. Require each sub-file to have the line
      # checked by Name of dept. XXX on date DDD
  (or "for release NNN", or whatever) somewhere in the file. This means that each sub-file must be modified for each build, but nothing in life is free.
• Supply the person responsible for receiving all these nuttsy-cuckoo sub-files a script that will scan each sub-file received for a given build for the presence of the checked-by line required in the previous step and check that the 'checker' for each department is authorized and the release date/number/whatever is correct for the build.
• Supply the person responsible for receiving all these sub-files a baseball (or, in British-influenced areas, cricket) bat. Place this bat in a prominent position in this person's cubicle or office under a sign that says "For Use On Anyone Who &#@%$ Up A Sub-File For Which They Are Responsible" in big red letters.
• Finally, do all the other checks on the sub-files that you can think of.

(some of the fake 'globals' may need to be initialized)

Aye, there's the rub; yes, there is a custom program that checks the files; that's what I'm going to improve. The trouble is that there are many of these global variables, coming and going. I'd love to find a way to identify them all and initialise them appropriately, in some totally automated way.

Bad idea letting anyone edit code

I confessed to it being crazy! There used to be six of us, all competent, never a problem. Now there are many more, some who know little Perl.

(one wonders at the source code change control system you have)

RCS for these files, CVS for all the code that reads them.

Don't store the hash in code, store it in...

Well, a database would be better. The problem is it's complex and large; the code that manipulates it will take a while to write.

perl -w /path/to/script.pl
[download]

Just do: perl -w /path/to/script.pl

The problem is that the warnings of Use of uninitialized value in string at... and Use of uninitialized value in concatenation (.) or string at... are quite overwhelming with uninitialised variables. The reported location is often many kilobytes of distance away from the actual error.

$ cat test-w
#! /usr/bin/perl

use strict;
use warnings;

my %hash = (
    fred => {
	qw( odd number of elem ents ),
    },
);
$ perl -wc test-w
test-w syntax OK
$ perl -we "require qq{test-w}"
Odd number of elements in anonymous hash at test-w line 6.

Is there a way to turn those uninitialised warnings off on the command line?

See perllexwarn (via warnings), especially no warnings 'uninitialized';

If this is a nested hash, I'd also check for use of refs (or objects) as the hash key.

On a related note, can anyone suggest a way of determining the location of the offending problem(s)?

Also: you may want to apply stricter rules to the format of the source code, than perl allows. For example, you could demand that new keys for the hash are always on a new line.

Perhaps you can build a validator for rules like these, using PPI? Don't spend too much time on it, or it might be faster to convert this to a database. Which is what I'd really recommend. (Maintain the contents with a generic CRUD tool, maybe build one with a CRUD builder toolkit; and access the DB contents with DBIx::Simple/SQL::Abstract, which is my preferred way to exchange data between Perl and an SQL DB.)