tags:

views:

65

answers:

2

I've been assigned to pick up a webapplication written in some old Perl Legacy code, get it working on our server to later extend it. The code was written 10 years ago by a solitary self-taught developer...

The code has weird stuff going on - they are not afraid to do lib-param.pl on line one, and later in the file do /lib-pl/lib-param.pl - which is offcourse a different file.

Including a.pl with methods b() and c() and later including d.pl with methods c() and e() seems to be quite popular too... Packages appear to be unknown, so you'll just find &c() somewhere in the code later.

Interesting questions:

  • Is there a tool that can draw relations between perl-files? Show a list of files used by each other file?
  • The same for MySQL databases and tables? Can it show which schema's/tables are used by which files?
  • Is there an IDE that knows which c() is called - the one in a.pl or the one in d.pl?
  • How would you start to try to understand the code?

I'm inclined to go through each file and refactor it, but am not allowed to do that - only the strict minimum to get the code working. (But since the code never uses strict, I don't know if I'm gonna...)

+1  A: 

I would write a utility to scan a complete list of all subs and which file they live in; then I would write a utility to give me a list of all function calls and which file they come from.

By the way - it is not terribly hard to write a fairly mindless static analysis tool to generate a call graph.

For many cases, in well-written code, that will be enough to help me out...

Paul Nathan
There is already code that will do that. If you have the `subref` use nothingmuch's [Devel::Sub::Which](http://search.cpan.org/~nuffin/Devel-Sub-Which-0.05/lib/Devel/Sub/Which.pm)
Evan Carroll
@Evan: That documentation contains *far* too much unsaid for me to use that. Also, I am not fond of dynamic analysis, since it leaves out unrun paths.
Paul Nathan
+4  A: 

Not using strict is a mistake -- don't continue it. Move the stuff in d.pl to D.pm (or perhaps a better name alltogether), and if the code is procedural use Sub::Exporter to get those subs back into the calling package. strict is lexical, you can turn it on for just one package. Such as your new package D;. To find out which code is being called, use Devel::SimpleTrace.

perl -MDevel::SimpleTrace ./foo.pl

Now any warnings will be accompanied by a full back-log -- sprinkle warnings around the code and run it.

I think the MySQL question should be removed, from this. Schema Table mappings have nothing to do with perl, it seems an out of place distraction on this question.

Evan Carroll
Thanks - the Devel:: thingie seems to have some interesting stuff that might help me. I will `use strict` in my code, I'm just not sure if I will obey the "strict" in "refactor only the strict minimum" ;)
Konerak