Main Content

When is a program complete?

Archive - Originally posted on "The Horse's Mouth" - 2011-01-06 08:41:26 - Graham Ellis

"Code is never completed ... it can always be improved." ... it's one of the most difficult aspects in many projects to say "yes, that does what we want and we should go for a release now rather than continuing to develop until ... until it's so late that we've missed the boat / added too much complexity to make the program useful and viable". Anyone who's managed a software project may be very familiar with this sort of decision, and how hard it is to make.

A similar thing happens with examples on our web site ... "Wouldn't it be nice if this example also showed xxx" we'll say to ourselves, or "should it also check for yyyy". But, alas, the result of adding in xxx, yyyy and zzzzz while we're at it means that the example is far less followable in showing the basic fundamental elements.

Yesterday, I recalled an example that reads a web server log file in a C program and stores pertinent elements into a growing array (via realloc) of structures. (See [source]). But the code included the opening of the log file as follows:
  fh = fopen("ac_20100630","r");
Now - that's all well and good, except that the program is fixed to a specific log file, and exited with a nasty segmentation fault if the file did not exist. Discussion ensued, and we modified the code to:
  fh = fopen(*++argv,"r");
  if (! fh) {
    printf("Oh Shdear ... no file\n");
    return (1);
    }


Better? Yes. Perfect? No! it would have been a good idea to echo out the name of the file we failed to open, give an excuse the reason, such as "no such file" or "not readable", etc ... all of which would have contributed to flannel which would render the original example far too dilute in what it intended to show.

A good approach that I've often taken is what I describe as "build up examples", where I keep a whole series of versions / snapshots showing how code has developed; here's such a series from yesterday, looking at handling the command line inputs in C which provided a very good and interesting example of handling of character strings, individual characters, and the arrangement of data into somewhat more complex layouts.
Step 1, Step 2, Step 3, Step 4

There's a further "build up" example showing the first use of structs (structures) in C ... and that's here:
Step 1, Step 2, Step 3

And even building up examples like that, we sometimes produce some interesting sideshoot examples - [here] is one that looks at the thorny issue of string comparison; written during the course, although it largely duplicates [this example] from the course.