RHOPGOOD@ucs.UAlberta.CA (Robert Hopgood) (02/21/90)
In article <17910@megaron.cs.arizona.edu>, gudeman@cs.arizona.edu (David Gudeman) writes: > >Documentation is over-emphasized. If you want to understand what some >code is doing, you have to read the code. There are certainly times >that the documentation gives useful hints, but only when something >obscure is going on. Any programmer should be able to read a code >fragment like > > for (lp = foo_list; lp; lp = Next(lp)) > Count(lp) += 2; > >as easily as the algebra example above, and no documentation should be >necessary. Note my use of the word "should". There are certainly >some incompetent programmers out there, but do you really want to >always cater to the worst case? >-- > David Gudeman >Department of Computer Science >The University of Arizona gudeman@cs.arizona.edu To start off with, there is more than the above reason to document code!!!!! I believe it is more important to DOCUMENT THE REASONS WHY you are doing what is coded. I just spent more than a week trying to figure out why the original programmers wrote a general ledger entry system the way they did. I did this because I am trying to correct a problem that has plagued the system that no one else has bothered to fix before. If you think it is easy to try to think like the writer, you must not haved had to work on someone else's programm. It also does not have to be someone else's programm, if it has been a long time since you wrote something that is somewhat involved and then worked on several other projects in the meantime, it can be very difficult to remember why YOU did what YOU did. I disagree with you, DOCUMENTATION is not emphasized any where near enough by programmers or the institutes that produce them.