home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / software / 5114 < prev    next >
Encoding:
Internet Message Format  |  1992-12-22  |  3.0 KB
  1. Path: sparky!uunet!noc.near.net!hri.com!spool.mu.edu!sdd.hp.com!hpscit.sc.hp.com!hplextra!hpcss01!hpcuhe!defaria@hpcuhe.cup.hp.com
  2. From: defaria@hpcuhe.cup.hp.com (Andy DeFaria)
  3. Newsgroups: comp.software-eng
  4. Subject: Re: C Code Layout
  5. Message-ID: <45360003@hpcuhe.cup.hp.com>
  6. Date: 21 Dec 92 23:49:23 GMT
  7. References: <1992Dec15.023235.17090@seq.uncwil.edu>
  8. Organization: Hewlett Packard, Cupertino
  9. Lines: 70
  10.  
  11. >/ hpcuhe:comp.software-eng / phardie@nastar.uucp (Pete Hardie) /  8:03 am  Dec 18, 1992 /
  12.  
  13. >>To me, such statements, while they require a close, should not require an
  14. >>open.
  15.  
  16. >I disagree.  Symmetry is desirable in a language. 
  17.  
  18. Symmetry for symmetry's sake is not a good argument in my book.
  19.  
  20. >>In other words the assumption should be that I always have a compound
  21. >>statement and must tell the compiler when it's done.
  22.  
  23. >Again, I disagree.  Since a compaund statement is lexically identical to a
  24. >single statement, they should have the same form.
  25.  
  26. Again a consistancy argument.  While I agree that consistancy is important,
  27. I'm not often thinking about lexically identity when writing code.  I'm more
  28. concerned with it's readablity, look and flow.
  29.  
  30. >>C required that I also specify an open but I see no reason to devote a full
  31. >>line to it!  I detest:
  32. >>
  33. >>    if (condition)
  34. >>       statement;
  35. >>   statement;
  36. >
  37. >I don't quite understance why this bothers you.  
  38.  
  39. Because it's too easy to mess up the alignment and end up with:
  40.  
  41.     if (condition)
  42.        statement;
  43.        statement;
  44.  
  45. and because it's too much of a bother to have to enclose it in braces merely
  46. to insert a debugging printf.
  47.  
  48. If you argue for consistancy then by always specifying braces you are more
  49. consistant but my argument is more "Every if statement opens, look for the
  50. closing brace".
  51.  
  52. >>    if (condition) {
  53. >>       statement;
  54. >>    } /* if */
  55. >>
  56. >>    statement;
  57. >>
  58. >>Note I label my terminating close (}).  Now think about it.  When eyeballing
  59. >>the above code and reading the if statement: Do you really care where it has
  60. >>opened or when it has closed?  To me the open is inconsequential: Of course it
  61. >>starts but where does it end?
  62. >
  63. >I think that this is why I prefer the braces on separate lines - to make
  64. >their associations clear.  
  65.  
  66. Again, to me the opening brace is inconsisquentcial (sp?) and needless
  67. syntaxtic sugar.  I guess I got this from programming in Modula-2 for a while.
  68. After working with a "all if's are compound - just tell me when they close"
  69. for a while I got used to it and said "This makes sense".  Again this is only
  70. my opinion.
  71.  
  72. >I dislike a comment that is placed for syntactic reference.  I prefer
  73. >comments be reserved for semantic clarification.  In some of the code I've
  74. >seen, there would be a forest of /* if */'s hiding the desired semantic
  75. >information.
  76.  
  77. I got used to this from Ada and it's "end if"'s and the like.  Again, it made
  78. sense to me to designate the end of such things as if's, while's, etc.  Sure
  79. having more information about exactly what thing this is brace is closing
  80. would be even more helpful but then you have to duplicate the (condition)
  81.