Path: utzoo!mnetor!uunet!husc6!hao!oddjob!gargoyle!ihnp4!cbosgd!mandrill!arun
From: arun@mandrill.CWRU.Edu (Arun Lakhotia)
Newsgroups: comp.lang.prolog
Subject: Re: code formatting (some amusing musings)
Message-ID: <2363@mandrill.CWRU.Edu>
Date: 13 Feb 88 05:03:36 GMT
Reply-To: arun@mandrill.UUCP (Arun Lakhotia)
Organization: CWRU Dept. of Computer Engineering, Cleveland OH
Lines: 96


Have you ever read a Pascal program that was completely left aligned.
Not too long, just about three pages. With global variables like 'x',
'xxx', 'yz' etc. What if the author came to you to find a bug in that
mess, and further told you that s/he would run it through a beautifier
while submitting the assignment.

Or have you ever seen a C program that was about 12000 lines long.
The whole program in just one file.

I have. And when I did see them, I knew they were bad programs written
by programmers who were taught the language constructs, but not
programming. There is no way i could appreciate them on grounds of
creativity, freedom of expression, individualism or anything else.

I have also seen nice elegant programs. And in most cases just the
stucture, layout or indentation tells you that the program is well
written. Elements of beauty are hard to express. But one you do come
across one there is usually a consensus on whether something is
beautiful.

Good programming style is a necessity not a luxury. From what I have
seen, people who have good programming style, spend less time in
debugging. Or else I know of people who since the last 3 months are
debugging a program that they wrote in only 5 days.

I strongly support Richard O'Keefe's view about programming. One
should program for human readability first and machine later. Its not
just for your successor. In the course of development of a project,
you may write the code only once, but read it several times. If you
try to save on typing, you end up spending time in deciphering. Using
'line_counter' instead of 'l' saves you the hassle of a mental
conversion of "'l' carries 'count of lines'" every time you read the
code.

Like Lagache and O'Keefe, I too have been a TA. I was grading Pascal
programs. In the very first assignment I set a guideline.

    A program *should* have procedures
    Procedures *should* have parameters
    Global variables *should* have meaningful names
    No procedure *should* be more than 1/2 a page
    begin/end *should* be properly matched and code indented
    There *should* be some comments, what-so-ever

Not that these rules define a good program. They just forced people to
use procedures and parameters: a concept that has a steep learning
curve or write sensible procedure and variable names that made grading
an assignment much more enjoyable. *Not* surprisingly I did get well
structured programs. And in most cases when the programs were well
structured they were also well written.

By no means are these guidelines to be complete, but i do appreciate a
need for some guidelines rather than a free-for-all world.  The above
rules do leave a whole lot to creative thinking. But all the same they
provide a guideline for a creativity that is appreciated at large.

I have met several people, especially in the industry, who are always
looking for a *quick and dirty* solution.  And i have always wondered:
Why does quick have to be dirty? I know it is easy to end up with a
dirty program very quickly. And when a dirty program does work
*correctly* I almost feel it is a miracle. Most of the time the
program is very complex with kludges thrown in left, right and center,
while there is always an equivalent program which may be very simple
and almost close to being trivial.

There has been an instance when I saw a very knowledgeable programmer
trying to code a simple algorithm that had a polynomial time
complexity.  But his programming process itself was of
Non-deterministic Polynomial time complexity (NP complete). It was
then that i realized that it is not just the time complexity of the
algorithm that is important, the time complexity of the programming
process is equally important. That could only be tackled by
evolving a sense of *good* style.

I do *not* claim that I am a great programmer. But i sure would like to
become one some day. And I do look forward to critiques like Richard
O'Keefe to shape my style. It's sad to see he is on a one man crusade
to shape the world. I am sure there are other grandmasters who share
his views and do hope they would speak up sometime.

There are several times I find O'Keefe's comments harsh. Pointing out 
spelling mistakes, which could very well be typos, too is not a very
convincing style of argument. But that to my mind does not reduce the
gravity of his concern otherwise. Alas!! every human is fallible.

I think O'Keefe's suggestion of running an experiment on programming
style is very neat. I hope there is someone out there in the
organization committee of the ICLP who would be listening (reading :-).

Arun Lakhotia

PS: A thumb rule for good programming from: Elements of Programming Style,
             Kerningham and Plaugher (I think).

     "KISS: Keep It Simple and Stupid..."