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.
(written 2008-10-24, updated 2010-06-23)

 Q904 - Object Orientation and General technical topics - Analysing a Programming Task
  [747] The Fag Packet Design Methodology - (2006-06-06)
  [1345] Perl and Shell coding standards / costs of an IT project - (2007-09-11)
  [1513] Perl, PHP or Python? No - Perl AND PHP AND Python! - (2008-01-20)
  [1607] Learning to program in Perl - (2008-04-11)
  [1850] Daisy the Cow and a Pint of Ginger Beer - (2008-10-21)
  [2327] Planning! - (2009-08-08)
  [2715] Uploading an image, document or pdf via a browser (php) - (2010-04-10)
  [2834] Teaching examples in Perl - third and final part - (2010-06-27)
  [3329] Perl from basics - (2011-06-20)
  [3366] Specification, Design, Implementation, Testing and Documentation - stages of a (Java) programming project - (2011-07-21)
  [3461] From flowchart to program - code design for the newcomer - (2011-09-29)
  [3895] Flowchart to program - learning to program with Well House - (2012-10-14)

P711 - An Introduction to Standards in Perl
  [242] Satisfaction of training - (2005-03-11)
  [668] Python - block insets help with documentation - (2006-04-04)
  [743] How to debug a Perl program - (2006-06-04)
  [945] Code quality counts - (2006-11-26)
  [965] KISS - one action per statement please - Perl - (2006-12-05)
  [1047] Maintainable code - some positive advice - (2007-01-21)
  [1221] Bathtubs and pecking birds - (2007-06-07)
  [1395] Dont just convert to Perl - re-engineer! - (2007-10-18)
  [1555] Advanced Python, Perl, PHP and Tcl training courses / classes - (2008-02-25)
  [1728] A short Perl example - (2008-07-30)
  [1863] About dieing and exiting in Perl - (2008-11-01)
  [2375] Designing your data structures for a robust Perl application - (2009-08-25)
  [2688] Security considerations in programming - what do we teach? - (2010-03-22)
  [2875] A long day in Melksham ... - (2010-07-17)
  [3398] Perl - making best use of the flexibility, but also using good coding standards - (2011-08-19)
  [4326] Learning to program - comments, documentation and test code - (2014-11-22)

Back to Perl and Blackberries

Previous and next or Horse's mouth home

Forward to Three Seasonal Pictures

November and December Public Course Schedule
A few of my favourite things
Volunteer v Employee - a skewed balance? (FSB)
Three Seasonal Pictures
Well structured coding in Perl
Perl and Blackberries
Pictures from a delegate
String matching in Perl with Regular Expressions
30th November - Santa Trip from Melksham