There is no real substitute for getting into the system and understanding how it works. Further, you have to know Perl fairly well, including good coding standards. I was recently helping a gentleman in the Netherlands with some Perl issues, when he emailed me a program and asked for feedback. Here's one of the subroutines:

sub stats {
unless ($aantalja) { &pak_getallen; }
$totaal_stemmen = ($aantalja + $aantalnee);
$eenstem = (100 / $totaal_stemmen);
$procentja = ($aantalja * $eenstem);
$procentnee = ($aantalnee * $eenstem);
    $procentja = int($procentja);
    $procentnee = int($procentnee);
if (($procentja + $procentnee) < 100) {
    if ($procentja > $procentnee) { $procentja+=1; }
    elsif ($procentja < $procentnee) { $procentnee+=1; }
}
}
[download]

Right off the bat, I can point to several problems. First, the subroutine is refers to variables declared outside of itself, so it's going to have side-effects that will be difficult to maintain. The indentation is poor, so it's tough to determine scope. Further, there's no sanity check to avoid a divide by zero error in this line:

$eenstem = (100 / $totaal_stemmen);
[download]

But does it work? Who knows? I don't speak Dutch. While there is plenty of information available in that little snippet, there is no meaning. Ultimately, this means that whatever metrics you want to produce, there is no substitute for understanding the code. Further, whatever metrics someone wants to put down as a standard, I guarantee that I can write code that will hit whatever target they are looking for, but still be an unmaintainable mess. Trust me, you should see some of my production code :)

Cheers,
Ovid

Join the Perlmonks Setiathome Group or just click on the the link and check out our stats.

sub stats {
  unless ($numberyes) { &grab_numbers; }
  $total_votes = ($numberyes + $numberno);
  $onevote = (100 / $total_votes);
  $percentyes = ($numberyes * $onevote);
  $percentno = ($numberno * $onevote);
      $percentyes = int($percentyes);
      $percentno = int($percentno);
  if (($percentyes + $percentno) < 100) {
      if ($percentyes > $percentno) { $percentyes+=1; }
      elsif ($percentyes < $percentno) { $percentno+=1; }
  }
  }
[download]



Greetz
Beatnik
... Quidquid perl dictum sit, altum viditur.

• Start with 1 for the "straight" path through the function
• Add 1 for each for, if, while, and, or.
• Add 1 for each case in a case statement

While strict adherence to complexity metrics can drive you crazy, they actually fit nicely into the programming mantra - high cohesion, low coupling. There's pretty strong evidence that if a function is doing a lot of conditionals it probably has low cohesion.

-derby

There's something fundamentally wrong with measuring complexity based on low level analyses of code and using the outcome to judge the quality of code.

Most people will agree the grammar of the musings of Shakespeare is much more complex than Dr Suess books. Does that mean the childrens books have a higher quality than the plays?

There are other problems as well. Such analyses can only focus on a particular implementation. It doesn't cast any judgement on a proper algorithm. It will favour a linear seach of a sorted array over a binary search, because the linear search requires less conditions to implement.

It doesn't mean you shouldn't use such a tool. It just means that you have to be very careful with what you do with its results.

Abigail

A2,

There's something fundamentally wrong with measuring complexity based on low level analyses of code and using the outcome to judge the quality of code

Didn't think I was. Everything else++. Except the part about Shakespeare and Suess - that's just silly.

-derby

I really don't think you're going to find what you're looking for in Perl. The grammatical nature of Perl makes parsing it exceptionally difficult ("Only perl can parse Perl") and so automated programs of this nature are nightmarish to write and even then won't catch everything. Nice things like eval, symbolic references, XS linkage, the ability to tweak so deeply into the engine, and other such things hammer us.

Yes, it has also been said that 'C doesn't have a grammar, C coders write their own with #define' but C seems a lot more regular than Perl does, and there's a lot more people willing to pay big money to people who can produce tools like this for it. Java obeys a nice simple grammar, which is why you see so many of these kind of tools for it.

All this being said there does seem to be good progress with the Perl Refactoring Browser, so possibly if someone was determined enough it may be possible to stand on their shoulders and produce code metrics from that. The Browser itself may do so, I've not looked that deeply into it to be honest, this'd help it detect the 'Code smells' that Refactoring is meant to solve.

So, how hard could it be to do that in Perl? Well, not that hard, if you're willing to be content with less than (but usually close to) 100% accuracy in the "precision and recall" measures of subroutine detection.

It's a real bare-bones, quick-and-dirty, not-too-subtle attempt, but it's here in case you want to try it out.

If somebody has enough free time to put something into a project like this, let me know. Particularly if you're familiar with the way the B:: modules work.

Hopefully this can be of some use to you as a rough measure of code density and scale of effort required.

Here's a quick example to get you started. First, run the code under a profiler:

$ perl -MDevel::Profiler -e 'sub foo { bar(); } sub bar { 1 }; print f
+oo();'
1
[download]

Then use the appropriate tool to generate a call-tree. In this case, dprofpp:

$ dprofpp -T
main::foo
   main::bar
[download]

-sam

strange that no-one mentioned this:

perl -MO=Xref yourscript.pl
[download]

I haven't tried it, but Perl Metrics seems pretty good at statistics, although unfortunately it doesn't appear to be actively mantained.

cheers,
Aldo

__END__
$_=q,just perl,,s, , another ,,s,$, hacker,,print;
[download]