You might take a look at the module B::Lint which does similar sort of things, albeit as a static check rather than at runtime, but it might give you a feel for what would be involved.

Getting offical approval to use one of the $^H bits (see S* strict.pm), and getting your code adopted in the core might be harder, but there would be nothing to stop you doing this for your own benefit.

* Corrected case of S. Thanks Bart.

Effective Perl Programming: Writing Better Programs with Perl has this to say about the issue:

It's not necessarily bad programming style to take advantage of Perl's independent namespaces by giving two different kinds of variables the same name. Sometimes it even seems like the sensible thing to do:

@who = grep { /\bjoebloe\b/ } `who`; [download]	@who contains output from who command, one line per element.
foreach $who (@who) { # ... do something with $who } [download]	Iterate over each line of output using variable $who.

--
Allolex

use B::LexInfo;
use strict;

# The name of the module to test goes in
# the next two lines.
my $module_name= "Data::Table";
use Data::Table;

my $lexi = B::LexInfo->new;
my $info = $lexi->stash_cvlexinfo($module_name);

foreach my $pad (@{$info})
{
  foreach my $sub (keys %{$pad})
  {
    my %lexhash;
    foreach my $next (keys %{$pad->{$sub}})
    {
      if ($next =~ /(\$)(.*)/ or 
          $next =~ /(@)(.*)/ or 
          $next =~ /(%)(.*)/)
      {
        my ($op, $varname)= ($1,$2);
        if (exists $lexhash{$varname})
        {
          print "$sub has lexicals $op$varname".
                " and $lexhash{$varname}$varname\n";
        }
        else
        {
          $lexhash{$varname}= $op;
        }
      }
    }
  }
}
[download]

use VerifyLexicalsWontConfuseTomA;
[download]

if you are willing...you could extend your code and make a "standards" module that could enforce coding guidelines for perl teams. this could check parantheses style, var name length, your var name pragma, etc. i don't understand how some perlmonks can get on a pedestal and preach to others that the open style is the only way--that's not the perl way at all. if "they" don't want to use this for their work, simply do not include this module. Individuality is a good thing, to a point...but on a team project, standards promote quality assurance. Chris

As one of those pedestal-ian monks, I'll try and explain it.

The issue is that every single Perl style guide I've ever seen has been a C or C++ style guide with funny characters thrown in. For example, using extra parentheses in C makes sense. The cases where the parens aren't needed or wanted are few and far between. However, adding parens to Perl everywhere you can makes it look like Lisp with a bad case of acne. (This is in the style guide for where I'm currently working. This is also the style guide everyone is ignoring.)

Most companies either don't know they're running Perl, think Perl isn't worth the time, are actively trying to phase out all open-source-dependent projects, or consider Perl to be a bastardized version of C. This is even more prevalent in Perl-based dot-coms. (The style guide in that place was even worse than where I am right now with all the idiotic parentheses!)

What I'm getting at is that standards are anything but, common sense isn't, and the rest of us are extremely wary of such a thing. This isn't to say that you shouldn't do it. In fact, if it works for you, I would love to help work on such a project! (It sounds neat-o keen. But, don't expect me to work within standards I didn't agree to... *grins*)

------
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.

# Under Construction
[download]

But no warnings for things that might confuse you. That's your own problem. Or maybe, perception. Because if you use both my $y and my @y, it wasn't confusing at the moment you wrote it. And since there's no possibility of actually confusing them - they remain quite distinct variables - Perl will not issue a warning.

And I think it should stay that way. Compilers should warn if there's the possibility of a mistake, but they should not have an opinion about coding style.

Abigail

This is not a question about whether it is a good idea or not. It's my time and my code, so that part is up to me!

It should work perfectly the first time! - toma

This is part of Perl's construct. In the Perl world - the difference is clear. Naming them similarly, and then using them interchangeablely or using them 'correctly' comes with time.

When I need an array - out of habit now - I do not create a scalar by that name (as in my mind it is now reserved for use when dealing with the array). The converse is true for me as well.

I personally, now that I am 'used' to this, find this feature of benefit as it lends itself to more streamlined coding and provides a built-in coding standard.

I was trying to read some procedural Perl about a year ago that was written by a C coder making a dip into Perl for the expediency. It was almost 1_000 lines long and didn't contain more than one or two variables that were longer than one letter. There isn't enough espresso in Abyssinia to keep my focus that strong.

This could be useful for keeping certain minimum style requirements in a tech group.