Re: Sub-initiate needs help getting started

[Lori713]

Just some random clarifications:

I wasn't very clear in describing the current "program" I'm taking over. There are two main files, one is the .pl that starts the processing, and the other is a .lib that contains all the subroutines. The .lib file is the monster with about 8000 lines of code.

There are not a lot of comments in the actual .lib file (I will be adding these as I figure out what each subroutine does). Without getting into the politics, my manager had no say over what this programmer did, or left behind. We just ended up being the ones to maintain it.

The global variables do begin with "g_" and the "xxx" part was me being lazy... There are some decent variable names in there (but I'm often confusing them with the "m_" variables with the same "xxx" part).

Another confession: I don't know how to build a test suite, but I'll dig around this website for ideas before asking for input right now on this node.

The subroutines are mostly Print statements to get the HTML to generate on the Web page; I don't see where any HTML template module was used. I have figured out how to do a HERE on my own (I think that's what it's called) so I won't have to type PRINT all the time. I have also looked a little at some of the HTML modules, and I think I'll try to use them.

A lot of the new reports are very similar in look and feel to the existing ones. At this point (and the looming deadline), I'll probably copy one of the reports, clean it up, and use it for a template for the new reports. I'm hoping that by putting my new reports in a separate file I can use -w and use strict.

Thanks for even more great pointers. I'm actually getting a little jazzed about starting in on this wooly mammoth!

[dragonchild]

Ok. A few notes on what you just said:
1. Templates were not used. If they were, you would have been handed a bunch of template files and would not see many print statements. You will want to set up one template for every different page that exists. Templates allow you to separate the form (how it's displayed) from function (what is displayed). There's a lot you can do with this.
2. Don't use heredocs for CGI display. They're just glorified print statements, essentially. You will want to use them for your SQL statements. Something like

   my $sql = <<__END_SQL__;
   SELECT a.foo, b.bar
     FROM some_table a,
          some_other_table b
    WHERE a.id = b.id
      AND a.name = ?
   __END_SQL__
   

   If you're wondering what the question mark is in that sql statement, look up placeholders in the DBI documentation. (Follow the link ...)

3. Test suites. There are oodles of books on the topic of testsuites, and testing in general. There are also dozens of threads at the monastery regarding them. The basics are this:
   • You have a function / script / webpage / whatever that has stuff it has to be able to do.
   • You want to verify that your thingy does what it's supposed to do. More importantly, you want to verify that it will return the appropriate error if it's given bad input. (Testing error cases is more important than testing success cases. Why this is true is left as an exercise for the reader.)
   • Look up Test, Test::Harness, Test::Cmd, Test::Cmd::Common, and the hundreds of other test suites that exist. For testing the CGI functionality, you're probably going to have to go to something like RationalRose or do it by hand. See if the testing group in your company has access to something like RationalRose or the like. Hand-testing forms is really annoying work.
   • Before you actually write your test-suite in Perl (or whatever), write it out on paper. List all the different types of input your thingy can possibly receive. Then (and this is the hard part) think about all the different types of bad input your thingy can possibly receive. For example, let's say you have a subroutine that updates the total of a foo. Your subroutine is given the name of the foo and the value. Are you making sure that the value is actually a number? (Look at Regexp::Common for help with that.) Are you making sure that the name is a valid name for a foo? Stuff can work and still have tons of bugs. (Look at Windows for an example of this.)

As always, feel free to post more questions, ideas, concerns, etc. Many of us (myself included) are more than willing to help you 1-on-1. Feel free to ask! :-)

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

The idea is a little like C++ templates, except not quite so brain-meltingly complicated. -- TheDamian, Exegesis 6

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

[duffbeer703]

Once you start getting a handle on things, you might find it helpful to use the Eclipse IDE (www.eclipse.org) with perl extensions (e-p-i-c.sourceforge.net). It's great for spotting syntax errors and figuring out what subroutines and regexes do.

[CountZero]

On the issue of IDE's and if your company can spare a few hundreds of dollars, the professional version of Komodo certainly warrants a closer look. I'm quite happy with it as it really speeded-up my programming. Of course, YMMV and many other Monks will surely tell you that the IDE they are using is far superior (and less expensive), but I'm happy with it and that's all I can say.

CountZero

"If you have four groups working on a compiler, you'll get a 4-pass compiler." - Conway's Law

[dragonchild]

Yep. vi is superior to all other IDEs! :-)

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

The idea is a little like C++ templates, except not quite so brain-meltingly complicated. -- TheDamian, Exegesis 6

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

[CountZero]

You may be not totally lost yet!

The "small" .pl program probably works as some kind of scheduler, calling the appropriate sub-routines from the .lib file as and when needed.

Mind you, using a .lib file instead of a properly packaged module (.pm) is certainly not considered a standard in the Perl-world.

Anyhow, the fact that subroutines are used in this .lib file is something "good".

Indeed, the way to go forward is trying to figure out what each sub-routine does. Even more important is to find out how the flow of execution runs through all these subroutines.

Knowing that, you can establish some hierarchy, see what data is passed around (in and out of the subroutines; do not forget that "global" variables may muddle/mess up this picture!) and what gets send to the web by which subroutine.

Having discovered all this you can then proceed, to carefully take apart the things which need to be changed and apply the necessary changes. It may seem like a chore but all this preparative work will help you later.

'Time spent in reconaissance is seldom wasted' they told us in the Army (to which one replied "A good scout is a dead scout" (Gen. Sherman, if I'm not mistaken))

CountZero

"If you have four groups working on a compiler, you'll get a 4-pass compiler." - Conway's Law