Here are the rules I follow. I use my unless there is a specific reason not to. I will use our for certain standard globals that need to be global, such as @EXPORT_OK. When I need to share variables across multiple files I try to use Exporter to export it from one place to all of the places that need it. If that solution won't work, then I will "use vars" for the declaration. I never use our for any variables that I've invented within my code.

I used to not use our for those standard globals. Instead I used to just initialize them before my use strict line. But it has been so long since anyone I care about has been using Perl 5.005 that I no longer worry about that.

I think we're more or less on the same frequency here:

If you are using our to access data within one package only, why are you making it a global when you could trivially make it a lexical?

I don't do that, and I didn't mean to imply that I did.

Here are the rules I follow. I use my unless there is a specific reason not to. I will use our for certain standard globals that need to be global, such as @EXPORT_OK. When I need to share variables across multiple files I try to use Exporter to export it from one place to all of the places that need it.

I'm with you so far.

If that solution won't work, then I will "use vars" for the declaration. I never use our for any variables that I've invented within my code. ...

I really don't see why you'd make that distinction. I just use our() for all package variables.
"What should it profit a man, if he should win a flame war, yet lose his cool?"

If that solution won't work, then I will "use vars" for the declaration. I never use our for any variables that I've invented within my code. ...

I really don't see why you'd make that distinction. I just use our() for all package variables.

Because if I have to type a variable name in two different files, my typo rate is fairly high. Therefore I really, really want to declare it in one file, and let strict.pm catch my typos everywhere else.

The only time I don't do that is when I'm working with an external API that doesn't give me the option. For example if I were to reinvent Exporter I would seriously think about pre-declaring @EXPORT_OK in the caller's space so that the caller can just access it and will get a useful error for accidentally typing @EXPROT_OK. Were I reinventing it for my own use, then I would definitely do that.

Let me think about it and see if there is any situation where I would use our in my own code. Hmmm.

There is one. And that is for a situation where I want a variable that I only access in one file but I want to use local on it. I'm not sure when that need might come up since it has never yet happened. Of course if Larry would allow local to be used on lexical variables, than that need would go away. (Note, he disallows it because of the potential for confusion, and not for technical difficulty. You can use local in more places than you might think - I like using it on the values of lexically scoped hashes.)