If you Export the variables, then you don't need to declare them at all in your script. :-)

I grant that it is fairly rare that you need to have 2 different files with code in the same package. But it does happen from time to time. For example you might encounter that at a first pass in refactoring some spaghetti. For another example some modules may need to autogenerate code in another package's namespace. In those situations it is better to use vars than to declare with our.

For my part, though, I would suggest that using our keeps down code smell (like spreading packages over multiple files). The fact that it makes those kinds of constructs harder is IMHO a feature. YMMV depending on context, of course :-)

Don't trust rules of thumb for code smells too much. For example odds are that you need to write a lot of small utilities. Odds are that there is a lot of common code around things like loading up the libraries you're always using, processing command lines, etc. The usual solution is to have a template you always start with. However what do you do if the template needs fixing? (Eg a new version of some module looks at an environment variable that old ones had not, and so breaks taint checking.) Also the framework code can get to be quite lengthy - which means that when you open up a script you have to scroll down for the code. That is no good!

A very good way to solve this problem is to move that common code off into a library that sits in package main. For example you might have a small module called Configuration::Bootstrap that will figure out your appropriate paths to your codebase and configuration, then loads Configuration. And Configuration in turn will load your config files, set standard global variables, process your command line, copy command line variables into global variables and declare them, etc. The result? Your starting configuration will look like this:

#! /usr/bin/perl
use strict;
use warnings;
use Configuration::Bootstrap (
    "help" => 0,
    "man" => 0,
    "database=s" => undef,
    # ...
);

use Company::Database;
use Company::Person;

# PROGRAM HERE




__END__

=head1 NAME

progname - Describe your program here

...
[download]

Sure, doing this means you have to have package main split across different files. It means that you have to use symbolic references. Etc, etc, etc. Lots of code smells.

But the smells are misleading you. This is actually a good thing to do, and it will make your codebase easier to work with. However when you do it, you'll see immediately why our would have been the wrong thing to do.

That said, this example notwithstanding, there aren't many cases where you want to split packages across files. However if you implement it, you'll find yourself using this one over and over again. :-)