I am a strong proponent of the "top-down" approach.....I feel it makes my Perl code easier to read/follow. I quote from "Learning Perl" that "[The subroutine] definition can go anywhere in the program file, though most people put it at the end".
:-) > Anthony (Tony) Esposito > Senior Technical Consultant > Inovis(tm), formerly Harbinger and Extricity > 2425 N. Central Expressway, Suite 900 > Richardson, TX 75080 > (972) 643-3115 > [EMAIL PROTECTED] > -----Original Message----- From: R. Joseph Newton [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 01, 2003 1:31 PM To: Aim Cc: [EMAIL PROTECTED] Subject: Re: Problem with script. 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] -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
