Path: utzoo!utgpu!watserv1!watmath!att!tut.cis.ohio-state.edu!ucsd!swrinde!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!uflorida!mephisto!mcnc!duke!romeo!drh
From: drh@romeo.cs.duke.edu (D. Richard Hipp)
Newsgroups: comp.arch
Subject: Re: religion and computer science
Message-ID: <20955@duke.cs.duke.edu>
Date: 23 Jul 90 13:17:57 GMT
Sender: news@duke.cs.duke.edu
Reply-To: drh@cs.duke.edu
Organization: Duke University CS Dept.; Durham, NC
Lines: 102

I've never taken an undergraduate computer science course.  But as
a computer science ABD (all but dissertation) I have taught a course in
introductory computer programming using Turbo-Pascal.  I learned quite
a lot about teaching programming from that experience, which I now wish
to share with the net as my contribution to the recent "indentation"/
"ivory tower" jehad.

I approached my course with what might be termed a "progressive" viewpoint.
Rather than give my students lots of rigid rules about indentation,
commenting, modularization, and so forth, I decided to give a few lectures
on some fuzzy, imprecise ideas of "good style" and "maintainability" and
then let each student program in whatever way their own creativity led.
This stretegy failed, and by the end of the course I had converted to a
programming demogogue, mandating a very specific indentation and commenting
style and prohibiting global variables and subprograms longer than 30 lines.
If I had it all to do over, I would be even more rigid.  Here's why:

1. Abuse of global variables:  I found that if students are allowed to use
   global variables, then they will use them to the exclusion of all else.
   This is especially true of students who have had prior exposure to BASIC.
   Passionate lectures on the virtues of modularity, information hiding,
   and re-entrancy are ignored.  The only way I found to get students to
   use local variables and subprogram parameters was to forbid the use
   of any global variables whatsoever.  This decree was meet by loud
   complaining but it was quite effective in improving the quality of the
   student's programs.  (I define quality as a combination of correctness,
   speed, and functionality, by the way.)

2. Lack of modularization:  Prohibiting global variables requires (in
   Pascal) that the students use at least one procedure.  Were it not
   for my second rule, "No subprogram longer than 30 lines", then many
   students would never use more than that single procedure.

3. Random walk indentation:  I initially allowed students to use any
   "consistant" indentation style.  Some students reasoned that no
   indentation is consistant, and so every line of their programs began
   at the left margin.  (This was the popular pick from the BASIC crowd.)
   The rest of the class must have assumed that a white noise process is
   "consistant" since for these students the left margin looked like the
   walk of a drunken sailor and was largely unrelated to the program's
   structure.  Both styles resulted in the same set of problems:
      a.  Students were unable to follow their own programming logic.
      b.  Students spent hours looking for silly errors such as a BEGIN
          without a matching END.
      c.  The instructor nearly went blind trying to read the student's
          code.
   Only after implementing rigid and uniform indentation rules was I
   able to bring some order to the students' programs.

4. Mystery variables:  Students would often come to me for help with
   programs they could not get to work.  After looking over their
   (uncommented) code, I would often ask some innocent question like
   "What does this variable/procedure/function do?"  The typical responce
   of the student was "I don't know".  After pressing further, I would get
   an explanation like "I must have put it there for some reason, but
   if forgot what that reason is."  My resulting frustration eventually
   led to a "comment every variable and subprogram" rule.  I refused to
   provide help on any program that was not commented.  This did not
   prevent useless comments such as

        var x: integer;   (* x is an integer variable *)

   but it did help some.  Late in the course I began requiring pre-
   and post-condition comments on every subprogram.  This was a great
   idea since it forced the students to actually stop and think about
   what they were doing for a change.  The improvement in program
   quality was immediate and very noticable.  Unfortunately, I added this
   requirement late in the course, and not all the students had time to
   catch on.  Next time, pre- and post-conditions will be in my first
   lecture.

There are more examples, but these will suffice.  I will now attempt to
analyze the problem at a higher level.

Programming well is difficult, especially for novice programmers.  In
designing a program, the programmer generally has more than enough to
worry about.  Allowing excessive freedom with regard to commenting and
indentation does the programmer no service -- it makes his job harder
by giving him more decisions to make.  Rigid rules of style do not
inhibit creativity -- it shifts the creative effort to where it belongs,
into the designing of the program's algorithms and user interface.

A recent wave of postings have flamed computer programming instructors
for their rigid rules of style, claiming that style doesn't matter, and
that the instructors should spend more time on important issues like
functionality.  Granted, functionality is much more important than style.
But one must remember that correct indentation is the EASY part of
programming.  Someone who is unable to comment and indent a program
according to the instructor's doctrine has a slim chance of succeeding
at the hard part -- making the program work.

Remember when you were learning to drive, and you instructor (dad) made
you keep both hands on the wheel at the 2 and 10 o'clock positions?  Do
you still drive that way?  Probably not, except in heavy traffic or other
situations which might require a quick response.  This is because you are
now comfortable with driving and able to safely do other things with your
hands.  Learning to program is analogous.  When you first start out, you
need a strict set of rules to keep you out of trouble.  After you acquire
some experence and become more confident in your abilites, the rules can
be relaxed somewhat.

'Nuf said.