Rushikesh K. Joshi
Department of Computer Science and Engineering, IIT Bombay

Sept 28, 2001

It's not a big lesson in Software Engineering, but just a few guidelines to help you write and organize
your simple programs better.
 

Have you done the conceptual work already?

Else when you start thinking about your design while you are programming, you end up with a
heap of patchy work. This produces programs that are not efficient, are difficult to understand,
difficult to modify and difficult to debug. Not only that. It also wastes a lot of your time, which
can be well spent on reading your course material. Do the conceptual work beforehand. Work out
your algorithms and data structures well before you start coding.

Have you got this piece of paper also with you?

Express on a piece of paper the design of the program which you want to develop. It can be
expressed in terms of interacting entities which you know you can implement without much
problems. Examples of these entities are files, objects, functions, and type structures.

Let your program remain 'executable' at any point of time

This gives you right from the beginning, a ready-to-execute program which starts executing
even before the entire code has been keyed in. It is this program that evolves as you keep
adding your entities to it.  You will always have ready with you, a runnable version of your
program. The program becomes fully functional only when everything is done.

Another advantage of following this style is that you will never be surprised by a long list of
errors and warnings at any time. It will save a lot of your time since you are adding entities one
by one. As soon as you add an entity, test it. If an entity is tested well, you have to worry a
little about it later, and only in cases where another entity passes on the buck to the tested
entity under use.

For  example, you can start with an empty main and take up the entities one by one. Complete
an entity, test it and go ahead with another. Languages like JAVA allow you to write a main in
every class, which can be used as a self tester.
 

Does it take too long to catch a bug?

Follow some of the known techniques. Take a walk, try again, take a printout of the buggy fraction
of your code and study the program off-line. If you are still unable to find the bug in your code,
show a demo of your program to a friend who is good at debugging. If you are taking large amounts
of time for fixing bugs, know that there is something wrong with your process of debugging.

You need to 'zero in' towards the bug as quickly as possible just as ants find their way into a leaky
packet of food. Don't blame the systems without showing concrete evidence, for having failed to find
a bug. Usually it happens only in rare cases.

Coding Style is important

Try this out: Pick up a program written by you a couple of years ago, why a couple of years, just
a couple of months. Try to make a functional change to it. Has it been easy? It will be so if the
program is well modularized, well commented, well indented, and elegantly designed.

There are many coding standards/style guidelines available for various languages. For example,
just compare the following 2 code fragments, the second one was produced by sending the first
fragment through a C beautifier program.
 

/* running this program will create /* a cpu-bound process that runs for 10 seconds */ main () { int i=0; alarm (10);         while (i<100) {         i = 20; } }

/* running this program will create /* a cpu-bound process that runs for 10 seconds */  main () {         int i=0;         alarm (10);         while (i<100) {                 i = 20;         } }

Summarily, Let's begin with a few questions:

Do you design before coding?
Do you think of the program after conceptualization, but before keying it in?
Do you program incrementally, module by module?
Do you test your modules as you go along?
Do you at any time, have a version of the program ready?
Do you spend enough time on design and save time on debugging?
Have you adopted a good program writing style?

end of article -------------------------------

PS1: Read some quotes of Edsger Dijkstra

PS2: Also read extreme programming guidelines and practices. This collection has come out of lessons learnt by software engineering practitioners. Some of these are for end-programmers, some for project managers, some for designers and some for testers. These guidelines are like too many spices spoil the taste or coriander is the last item to be added . These tips can be reasoned about and are based on years of observation about the successful dishes and some failures. These are what good coders, good designers, good managers already know of. It doesn't take long for a newbie on his own to spoil a dish, but following the advise of an old lady in the house, kudos come quicker than expected. Similarly, for a fresh programmer, lessons begin with following guidelines and end with their affirmation through one's own experiences, both desirable and undesirable.