Yeah I do use this style as well. However it still presents duplication when you want to provide defaults or multiple names or types for options (which rules out a quick key %opts), in fact its worse because you dont have compile time var name checking of the var names if they get out of synch. In other words the connection between destination and source becomes too loose and it becomes really easy to make a subtle error

my %opt={verbose=>0,all=>0);
GetOptions(\%opt,'talkative|verbose','everything|all');
[download]

So what happens if we werent careful and do it like

GetOptions(\%opt,'talkative|verbose','all|everything');
[download]

Oops, now the --all options goes to the wrong place.

Anyway, I still would use the %hash style as well for some situations, and as the interface to Getopt::Long is so flexible you can mix the two:

GetOptions(\%opts,'Debug=i'=>\(my $Debug=0),'verbose','all');
[download]

And then theres also using subs for the options... Mmm fun!

Personally, I tend to keep thingsl ike synonyms in a data structure of their own. So, I might do something like:

my %options = (
    verbose    => 0,
    everything => 1,
);

my %synonyms = (
    verbose => [ qw(
        talkative
    )],
    everything => [ qw(
        all
    )],
);

GetOptions(
    \%options,
    (
        map { join\('|', $_, @{ $synonyms{$_} || []}) } keys %options
    ),
);
[download]

This way you can, at a glance, see exactly what your synonyms are, laid out nice as can be. A similar thing can be done with the "=i", "=s", etc.

------
We are the carpenters and bricklayers of the Information Age.

Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.

Please remember that I'm crufty and crochety. All opinions are purely mine and all code is untested, unless otherwise specified.