home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / software / 4880 next >
Encoding:
Internet Message Format  |  1992-12-11  |  2.8 KB
  1. Xref: sparky comp.software-eng:4880 comp.lang.c:18204
  2. Newsgroups: comp.software-eng,comp.lang.c
  3. Path: sparky!uunet!cis.ohio-state.edu!zaphod.mps.ohio-state.edu!saimiri.primate.wisc.edu!ames!ncar!csn!raven!rcd
  4. From: rcd@raven.eklektix.com (Dick Dunn)
  5. Subject: Re: C Code Layout
  6. Message-ID: <1992Dec11.165835@eklektix.com>
  7. Organization: eklektix - Boulder, Colorado
  8. References: <1992Dec7.164154.6312@b30.ingr.com> <BywqDo.F8F@monster.apd.saic.com> <1992Dec10.191917.18184@yarc.uucp>
  9. Date: Fri, 11 Dec 1992 16:58:35 GMT
  10. Lines: 44
  11.  
  12. scott@yarc.UUCP (Scott Beckstead) writes:
  13. >tomj@monster.apd.saic.com (Tom Johnson) writes:
  14. [example of revision author/date/synopsis list
  15. >>I've always wondered about this sort of thing in a source file.
  16. >>Is this sort of information considered useful?...
  17.  
  18. Realize again (as others have noted in passing) that "is this...useful?" is
  19. a separate question from "should it be in a source file?"  Lots of us will
  20. say it's indispensable, but doesn't belong in the source itself; it belongs
  21. in the information kept by the control system, where you can get to it if
  22. you need it but it's not constantly in your face.
  23.  
  24. Scott then talks about noting each change in the source itself:
  25. >...Tags were left in the source of the form /*SHB01A.1*/ at each
  26. >changed location. It was then quite clear when/why the change was made
  27. >and related this to the top line that had this tag...
  28.  
  29. This only works for a little while.  It doesn't scale to longer-term
  30. development, because the source code gets so cluttered with these little
  31. comments that you really can't understand their relationship any more.
  32.  
  33. >...This technique was MUCH better than
  34. >trying to diff  a file that may have been changed 5 or 6 time before I
  35. >had to look at it...
  36.  
  37. Your code-control system ought to be able to hand you a "diff" representing
  38. the changes between any two given revisions.  For the differences between
  39. two consecutive versions, it's about a wash for comments in-line versus the
  40. diff.  If you're stuck in the (all too common) situation of "it worked in
  41. version 37; it's broken in 42" you'll most likely want to see the
  42. accumulation of changes between those versions...including the fact that
  43. some changes may have been made, then undone.  Also, what the code does is
  44. (at least arguably) more important than what it did--in the sense that the
  45. contents of the code should be most useful to the person working on it as
  46. it stands.  Change archaeology is important but should take a back seat.
  47.  
  48. But some of that issue--how to understand the changes--is obviously depen-
  49. dent on how people work and look at code.  My main point is that it doesn't
  50. extend to long-term development...I've actually watched it fail.  Took
  51. about a year of relatively active development to make source code nearly
  52. unreadable.
  53. -- 
  54. Dick Dunn    rcd@raven.eklektix.com   -or-   raven!rcd    Boulder, Colorado
  55.     ...Straight, but not narrow.
  56.