Well structured coding in Perl

Archive - Originally posted on "The Horse's Mouth" - 2008-10-24 06:40:58 - Graham Ellis

Write a small code utility - a few lines - and you can simply start at the top and work through to the bottom. But as the code increases in length, you're going to want to take out common code and put that code into named blocks that can be re-used. Extending this technique, you can break all your code into named blocks - which can be arranged in tree. And this is a structured program.

With structured programming, your main code doesn't exceed a page (deliberate woolly definition of what I mean by a page!) and calls a series of other major blocks of code, each of which has the same maximum size. This major blocks then call other less major blocks, and so it goes on. What does this technique give you

• easily readable sections of code - especially if you write each of them to good standards/

• The ability to modify you application easily by adding in and taking out chunks of code - it's like working with Lego bricks rather than as an organ transplant surgeon

• A clear scheme under which you can test the code segment by segment if need be, writing test harnesses for each part, dummying sections in if you need to

• The ability to store commonly used elements into seperate code files so that they can be re-used across a lot of programs.

Illustration - a delegate on a private Perl course run on a customer's site in East Anglia

But when you're developing code it is - I admit - sometimes hard to see where the stucture should lie - initial advise is if you are tempted to copy and paste a block of code, thing twice and make it a named block if you possible can. Further advise, though, where you're not likely to have such initial high re-use is write pseudo code to start with - the application being just a few comment which turn quickly into calls in the langauge of choice and are then filled in with a few extra surrounding variables for transferring / passing data.

Yesterday, I wrote an example along these lines in Perl. Of all the languages we teach, Perl is perhaps the easiest one for people to write code that's a real "dog's dinner" that's impossible to follow later - "write only coding" is another name for it. But in this example, you'll see that you can quickly get an idea of what's going on, even from just the main code:

# Read the data

@p_records = suck("../requests.xyz") or die ("No data");

 

# Find the Perl records and produce a title and report

@rin_order = &massage(@p_records,"Perl");

titleit("People who know Perl");

blow(@rin_order);

 

# Find the Java records and produce a title and report

@rin_order = massage(@p_records,"Java");

titleit("People who claim to know Java");

blow(@rin_order);

In this example, I wrote the named blocks of code (know as subs in Perl) into the end of the same file ...

# -----------------------------------------

 

use strict;

 

sub suck {

  my ($infile) = @_;

  @_ == 1 or die ("Bad Call to suck");

  print ("$infile\n");

  open (FH,$infile);

  <FH>;

  }

 

sub massage {

  my (@records) = @_;

  my $skill = pop @records;

  grep(/\b$skill\b/,@records);

  }

 

sub blow {

  foreach (@_) {

    my @parts = split;

    printf ("%14s ",$parts[0]);

    foreach my $skill (@parts[1..$#parts]) {

      printf("%10s ",$skill);

    }

    print "\n";

  }

  1;

  }

 

sub titleit {

  print "\n";

  print $_[0],"\n","-" x length($_[0]),"\n";

  }

Some further things to note ...

• an absence of global variables within the subs - everything is passed in and out to make the code elements work cleanly and clip together in an obvious way. This absence is forced / validated by the use strict in the code.

• the hiding of more complex logic within the individual subs - there's no need for the top level programmer / person re-using the subs to get involved with the detail of what goes on internally - just like you don't have to know how to drive a train to travel on one. (This is known as "encapsulation")

• the LACK of comments in each sub. This is very arguable - each sub should really have a short note of what it does, but there is certainly no need to document each and every line!

• the use of spaces, and good, consistent, variable names to supplement the understandability of the code (you could consider these to be "comments which are not comments")

I'm teaching another Perl Course next week, a further one at the start of December (that's a private course so you won't find it on the schedule) and then further ones early next year. After being slightly unfashionable for a while (as we wait and wait for Perl 6), it seems that many people have given up waiting and are finding that Perl 5 remains pretty darned hard to beat. I agree - fabulous language - you can do a lot in a very little code, even if it does require strong management to avoid the "dog's dinner" look.

Main Content

Well structured coding in Perl