Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uwm.edu!rpi!zaphod.mps.ohio-state.edu!mips!cs.uoregon.edu!ogicse!intelhf!ichips!iwarp.intel.com!inews!bishop!bhoughto From: bhoughto@bishop.intel.com (Blair P. Houghton) Newsgroups: comp.lang.c Subject: Re: A question on C programming style Message-ID: <3903@inews.intel.com> Date: 19 Apr 91 03:20:56 GMT References: Sender: news@inews.intel.com Organization: Intel Corp, Chandler, AZ Lines: 34 In article cschmidt@lynx.northeastern.edu writes: Sounds like a great idea, but... >The header generator program encourages you to divide the input source >file into two sections. (Actually, there are four section types in >all, but this is enough complication for this message.) Ick. Constraints on source layout are often much more trouble than they're worth. Can you make it smart enough to simply create correct external declarations in the .h from all things defined in the .c (all things with external linkage, that is)? Plus all #defines? Generally programmers put definitions of objects in the region of the file preceding the first function definiton. Sometimes, however, it's useful to keep certain constants and variables close to the function that uses them, so one can cut and paste the function if the entire package isn't needed. It's not any harder to find a variable definition in the middle of a file than at the beginning, especially when the file defines several hundred variables. I can see how it would be a couple of orders of magnitude easier to do it with an explicit dividing line between objects and functions, though. You didn't mention it, but the .h file should also contain the prototypes of the functions in the .c file, of course... --Blair "I laughed, I cried, I compiled my popcorn..."