Re: Hungarian notation

[peter@fourier.newcastle.edu.au (Peter Moylan)]

Richard A. O'Keefe (ok@goanna.cs.rmit.EDU.AU) wrote:
>nreitzel@lonestar.jpl.utsa.edu (Norman L. Reitzel   ) writes:
>>As for serious code, I've ported million line projects for a telephone 
>>company, and managed projects that produced twice that.  The key to 
>>maintainability is defensive programming, and ADEQUATE BLOCK COMMENTS.  
>>Any chunk of code that does not contain info about what it does and how 
>>it does it is an error waiting to happen.  The rude concept of 
>>"self-documenting" code belongs in an ivory tower with those who teach, 
>>not in the trenches with those of us who DO.

>Those of us who teach struggle hard to persuade students to write
>good comments.

I don't know where this myth comes from.  In my 20+ years in
academia, I have NEVER met a software teacher who considered
uncommented code to be acceptable.  Practically everyone tries
to get across the message "write the comments first, and then
the code".

Take a look at some of the literature on "literate programming".
I'm not convinced myself that that's the solution, but at
least it does illustrate the attitude, which is very common
in academia, that the comments are more important than the code.

It's true, however, that it's very difficult to get students
to listen to this message.  The value of comments seems to be
a "hindsight" thing that one learns only by first making some
bad mistakes.

I adopted a policy, years ago, of never agreeing to help
debug badly-documented code.  When I'm asked questions like
"why doesn't my code work", my response is along the lines
of "come back after you've inserted the comments, and we'll
look at it then".  Half the time they don't come back, 
because they discover the error themselves while debugging
the comments.

One of the subjects I teach involves a large team
programming job.  Typically the work progresses very badly
for the first few months, but by the end of it the students
have learnt something about the importance of good
communication among team members.  I don't particularly
care whether the final product is a good one - usually it
isn't - provided that the students have properly learnt the
lessons about how to do it better next time.  The major
value of this subject, in my opinion, is that it teaches
students by experience that a large software project is
radically different from "hello world" programming.

>Fifty years of programming language research, and we end up with C++ ???

A long-standing debate in academic teaching circles is over
the question of whether one should teach a good programming
language, or teach the one that's most commonly used.
Years ago this debate was about COBOL, and in the end most
CS departments stuck to their guns and dropped COBOL, over
the protests of most employers, on the grounds that it was
simply perpetuating bad practice.  Now COBOL is almost a
non-issue and the focus of the debate has moved to C and C++;
but this time around the CS departments - most of them,
anyway - have opted for the morally lazy solution.  Everyone
seems to have forgotten the message that universities are
supposed to be looking to the future rather than simply
trailing the pack.

Some of my colleagues in another department are still using
Fortran as their teaching language, based on an "industry
practice" argument.  Apparently they haven't yet noticed
that industry practice is moving on and leaving them behind.

--
Peter Moylan                           peter@ee.newcastle.edu.au
                  http://www.eng.newcastle.edu.au/ee/Moylan.html
OS/2 freeware list at 
      http://www.eng.newcastle.edu.au/ee/Moylan/os2/os2info.html