home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / lang / c / 19058 < prev    next >
Encoding:
Internet Message Format  |  1992-12-30  |  2.7 KB
  1. Path: sparky!uunet!zaphod.mps.ohio-state.edu!swrinde!gatech!destroyer!ncar!noao!amethyst!organpipe.uug.arizona.edu!news
  2. From: dave@cs.arizona.edu (Dave Schaumann)
  3. Newsgroups: comp.lang.c
  4. Subject: Re: Function definition style
  5. Message-ID: <1992Dec31.023318.4947@organpipe.uug.arizona.edu>
  6. Date: 31 Dec 92 02:33:18 GMT
  7. References: <1992Dec30.223045.29467@news2.cis.umn.edu>
  8. Sender: news@organpipe.uug.arizona.edu
  9. Reply-To: dave@cs.arizona.edu (Dave Schaumann)
  10. Organization: University of Arizona
  11. Lines: 51
  12. In-Reply-To: wright@staff.tc.umn.edu (Mark Wright)
  13.  
  14. In article <1992Dec30.223045.29467@news2.cis.umn.edu>, wright@staff (Mark Wright) writes:
  15. >Is there any good reason not to use the following style for defining
  16. >functions:
  17. >
  18. >type function_name( varname1, varname2, varname3 )
  19. >
  20. >type varname1;
  21. >type varname2;
  22. >type varname3;
  23.  
  24. Well, if your compiler can't deal with ANSI-style declarations, that's
  25. about the only choice you have.  Also, if you're extremely concerned
  26. about portability, and for some reason don't want to use the de-protoizer
  27. utility that's freely available, you might also do this.
  28.  
  29. The bad things about this are:
  30.   1. The compiler can't do parameter type-checking or auto-casting like it
  31.      can with prototypes.
  32.   2. This style of declarations has subtly different semantics from
  33.      prototyped declarations.  A sloppy programmer might decide to
  34.      play mix-n-match, which can lead to subtle, nasty bugs.
  35.   3. Although it is still supported, presumably old-style declarations
  36.      will someday be one with history.  All programs with old-style
  37.      declarations will either have to be abandoned or proto-ized.
  38.  
  39.  
  40. >I try to use the style in ansi k&r, but I notice that others are using this
  41. >style and I assume they aren't all using pre-ansi compilers.
  42.  
  43. IMHO, one should be *very* careful in picking up coding habits from other
  44. programmers.  Often a programmer will use a particular feature or style
  45. out of laziness or ignorance of superior alternatives.
  46.  
  47. >My problem is that to use Brief's function listing command the end paren must
  48. >be on the same line as the function name,
  49.  
  50. Oh, yeah.  Another reason programmers continue bad habits is to support
  51. broken tools.  IMHO, you should complain to the vendor and/or seek an
  52. alternative.  There's at least a few C-function utilities available in
  53. the comp.sources.(unix|misc) archives.  I also have a simple function
  54. lister I wrote myself, which is not dependant on where you put new lines
  55. in your code (drop me a line if you're interested...)
  56.  
  57. If you still think pre-ANSI style declarations are better, just remember
  58. every time you have a bug caused by mis-matched parameters or return type,
  59. you should say
  60.  
  61.   "If I were using prototyes, the compiler would've caught this".
  62.  
  63. -- 
  64. Caught an internal error--.brainrc restored
  65.