Aim wrote:
> Hi,
>
> Thanks for your input. I thought my script was neat and organised and utilised subs,
> I guess my standard is much lower than yours.
It's not really an issue of lower or higher standards. When we are in the thick of
it, it all makes sense. We have a few million neural circuits patterned to the
elements of the problem, and the context seems quite clear.
While we are in the thick of it.
> I try not to use too many subs as most of my scripting is short and simple, and I
> fear overkill if I do use subs. But your advice on mental powers seems to be true, I
> am now finding it difficult to cure what can only be a simple bug.
This is what they call the "teaching moment."
> Going back to the drawing board may be inefficient in this case as the script is
> almost there, I can feel it. The mistake I made was pausing from the work for a few
> days and then to come back to it scratching my head.
If you feel that this stage of your project is very close to completion, it might be
wrth the digging just to get a prototype up. Bjarne Stroustrup, the creator of C++,
made a very good popint about prototypes:
"Prototypes are to be used, then thrown away."
There have been a few times that disaster--having days worth of work go up in a flash
because I had failed to save and then had my IDE crash--turned out to be of benefit.
Usually, I could reconstruct the work in a fraction of the time it took first time
around. I could also reformulate from the base some awkward constructs that had been
crwling under my skin.
> I will await further responses at the same time give debugging another shot and if
> it does not work I will have to follow your advice.
>
> Many thanks.
I would leave it to your judgement whether you can make use of the existing structure
for your immediate phase. If you want to do this, I would strongly recommend adding
documentation to your script. Do perldoc perlpod for the reference on inline
documentation. You can scan through you lib directoies and read some *.pm files to
get an idea of how the protocol is used. This at least is critical.
You need some plain-language description of the fuctionality expected, and what part
the various sections of code are meant to play in it, in order to have context in
which to evaluate whether the code is working, or do decide what needs to be done to
make it work better.
I'm actually moving back towards the elimination of scripting content from my Perl.
This doesn't apply so much to the short sample scripts I use to test isolated
concepts, but I don't think I would start a new real-life program with any critical
data declared in the global namespace. One advantage to this approach is
self-commenting--an appropriately chosen name for the driver routine communicates the
overall purpose of the process
#!perl -w
# payroll.pl
# Processes periodic payroll
use strict;
use warnings;
use This;
use That::TheOther;
# Global information up here as constants, easily locatable for modification
use constant PAYROLL_FILE = 'localpath/filename.ext';
use constant HOURS_TABLE = '"MySQL", "PROD", "HOURS"';
use constant EMPLOYEE_TABLE = '"MySQL", "HR", "EMPLOYEE"';
sub generate_payroll();
sub get_employee_info();
sub process_payroll_info($);
sub extract_employee_key($_); # indents may not communicate that well
# if functions are called from
different nesting levels
generate_payroll();
sub generate_payroll () {
my $employees = get_employee_info() or die "Could not retrieve employee
information\n" .
" This process cannot initialize\n";
foreach (@{$employees}) {
process_payroll_info($_);
}
}
sub get_employee_info() {
return 0;
}
process_payroll_info($) {
my $profile_ref = $_;
my $employee_key = extract_employee_key($profile_ref ) or {
warn "could not find employee ID";
return 0;
};
print "Processing payroll for employee with ID $employee_key\n";
my $hours = get_current_hours($employee_key);
}
extract_employee_key($_) {
return 0;
}
At this stage of development, I don't know a thing about the internal organization of
many of the processes called. It doesn't matter. I can deal with each as I get to
it. Even with totally empty code, I can see the overall process carried out. Once
the details of each subprocedure come into play, they have a context in which to fit.
That context will be invaluable as the program grows in scale.
Try playing around with the top-down approach a little, and see how it works for you.
Joseph
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
