Re: Confusing variable names

Thanks to BrowserUK I got on the right track looking at the B modules. I decided to narrow the problem down to finding lexical variables in modules, since almost all my variables are of this sort. I didn't see how to handle lexical variables using the techniques in B::Lint, but I ran across B::LexInfo. This just about gets me what I want, although it hasn't been tested thoroughly:

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]

I could make this a module and add a little more B code to it, so that it would check a whole program and all the loaded modules. I could use it with something like:

use VerifyLexicalsWontConfuseTomA;
[download]

It should work perfectly the first time! - toma

Comment on Re: Confusing variable names Select or Download Code

Replies are listed 'Best First'.
Re: Re: Confusing variable names by aquarium (Curate) on May 05, 2003 at 21:54 UTC
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	[reply]
Re3: Confusing variable names by dragonchild (Archbishop) on May 06, 2003 at 14:07 UTC
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.	[reply]