home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / software / 4990 < prev    next >
Encoding:
Text File  |  1992-12-15  |  2.3 KB  |  50 lines
  1. Newsgroups: comp.software-eng
  2. Path: sparky!uunet!spool.mu.edu!uwm.edu!linac!att!cbnewsm!lfd
  3. From: lfd@cbnewsm.cb.att.com (Lee Derbenwick)
  4. Subject: Re: C code Layout
  5. Organization: AT&T
  6. Date: Tue, 15 Dec 1992 18:04:36 GMT
  7. Message-ID: <1992Dec15.180436.28384@cbnewsm.cb.att.com>
  8. References: <1992Dec14.074411@eklektix.com> <KANZE.92Dec15171105@slsvdnt.us-es.sel.de>
  9. Lines: 39
  10.  
  11. In article <KANZE.92Dec15171105@slsvdnt.us-es.sel.de>,
  12. kanze@us-es.sel.de (James Kanze) writes:
  13.   [ in answer to one of my comments on excessively large comments: ]
  14. > |> One reason that I personally dislike very large comments embedded in
  15. > |> the code is that they greatly reduce the amount of code within my
  16. > |> visual field (whether on a screen or on paper)  [ ... ]
  17. > 
  18. > I was surprised that this argument wasn't mentioned earlier in this
  19. > thread, as it seems quite popular, at least amongst Cambridge
  20. > graduates, where it seems to be called the band width theory.  [ ... ]
  21. > 
  22. > Of course, this means that you also put several short statements on
  23. > the same line, code on the same line as the opening brace, etc.  And
  24. > of course, you never, never leave a line blank.
  25. > 
  26. > This also argues for short variable names.  (They increase the chances
  27. > of getting more than one statement on a line.)
  28.  
  29. Let's start with the opposite extreme.  Should we mandate 1000 lines
  30. of comments for every line of code?  No?  Okay, "We've established
  31. what you are, now I'm trying to establish your price."  :-)
  32.  
  33. Certainly at _some_ point you have too many comments.  Similarly, if
  34. you make the code too dense, it becomes unreadable.  The question is,
  35. where is the appropriate point?  The "band width theory" is a useful
  36. metric, but it is only one of the driving forces.  "Chunking" of
  37. concepts has already been mentioned in this thread as another driving
  38. force.
  39.  
  40. Just taking these two into account can lead to some guidelines for
  41. where large comments should be.  A 10-line comment detailing a tricky
  42. (but not terribly long) loop is likely to interfere seriously with
  43. "chunking" if it is embedded in the middle of the loop.  But the same
  44. comment, placed before the loop (and set off by blank lines!) will
  45. convey the information without interfering with the visual cues.
  46.  
  47.  -- Speaking strictly for myself,
  48.  --   Lee Derbenwick, AT&T Bell Laboratories, Holmdel, NJ
  49.  --   lfd@cbnewsm.ATT.COM  or  <wherever>!att!cbnewsm!lfd
  50.