home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / software / 4942 < prev    next >
Encoding:
Internet Message Format  |  1992-12-14  |  3.1 KB
  1. Path: sparky!uunet!zaphod.mps.ohio-state.edu!cs.utexas.edu!qt.cs.utexas.edu!yale.edu!jvnc.net!darwin.sura.net!uvaarpa!concert!borg!news_server!martinc
  2. From: martinc@hatteras.cs.unc.edu (Charles R. Martin)
  3. Newsgroups: comp.software-eng
  4. Subject: Re: C CODE LAyout
  5. Message-ID: <MARTINC.92Dec14120615@hatteras.cs.unc.edu>
  6. Date: 14 Dec 92 17:06:15 GMT
  7. References: <1992Dec11.020200.944@seq.uncwil.edu>
  8.     <MARTINC.92Dec11214534@hatteras.cs.unc.edu>
  9.     <1992Dec14.084405@eklektix.com>
  10. Sender: news@cs.unc.edu
  11. Organization: UNC Department of Computer Science
  12. Lines: 53
  13. In-reply-to: rcd@raven.eklektix.com's message of 14 Dec 92 08:44:05 GMT
  14.  
  15. In article <1992Dec14.084405@eklektix.com> rcd@raven.eklektix.com (Dick Dunn) writes:
  16.  
  17.    martinc@hatteras.cs.unc.edu (Charles R. Martin) writes:
  18.    ...
  19.    >If I read it aright, Herbst "likes a format that leaves the code free of
  20.    >clutter" and therefore prefers to limit in-code comments to only those
  21.    >few setting off the sections, plus some comments on the general meaning
  22.    >of the code.
  23.  
  24.    I read it somewhat differently.  I understood him to be objecting to
  25.    comments-for-comments-sake.  
  26.  
  27. That's precisely the reason I phrased it "if I read it aright" of
  28. course.   
  29.    
  30.    I don't see any objection to comments
  31.    describing difficult points, unusual constructs, etc.--although I'm led to
  32.    a feeling that I have, that the way to fix obscure code is to remove the
  33.    obscurity, and that therefore commenting around it is an admission of
  34.    defeat.  Better to comment than to leave it obscure and unexplained, of
  35.    course!
  36.  
  37. In the device driver I've been writing in my day job, I've just gone
  38. through an exercise of taking my nice clear code and re-writing it
  39. obscure in some essential areas as a performance optimization.  We're
  40. down to that last little bum an instruction here and there phase in an
  41. otherwise working driver.  I would normally agree with you about recode
  42. it clearer, but sometimes you cannot.
  43.  
  44.    >I frankly have always found it very difficult to believe that anyone who
  45.    >suggests such a style has any professional software engineering
  46.    >experience...
  47.  
  48.    Let me try to help you believe it.
  49.  
  50.    I think the first matter is to narrow in on what the real difference is
  51.    between your perspective and Herbst's.  You've obviously been burnt by code
  52.    with inadequate commenting, Herbst by overcommented code.
  53.  
  54. Rather than continue the point-by-point, let me propose a different
  55. model of the difference: I think the difference is that Herbst's model
  56. is that the difficulty of understanding is a *result* of "too many"
  57. comments ("hiding the code"); mine is that difficulty of understanding
  58. is a result of insufficiently informative comments.  As I said in
  59. passing in an earlier post, I think one of the troubles here is that the
  60. number of comment lines isn't necessarily coupled with how informative
  61. they are.
  62. --
  63.         Charles R. Martin/(Charlie)/martinc@cs.unc.edu
  64.      Dept. of Computer Science/CB #3175 UNC-CH/Chapel Hill, NC 27599-3175
  65.         3611 University Dr #13M/Durham, NC 27707/(919) 419 1754
  66.      "Oh God, please help me be civil in tongue, pure in thought, and able
  67.       to resist the temptation to laugh uncontrollably.  Amen." -- Rob T
  68.