jmc@ptsfa.UUCP (Jerry Carlin) (02/27/88)
In article <5303@well.UUCP> pokey@well.UUCP (Jef Poskanzer) writes: >Recap: I pointed out that the Unix linker includes all the routines that >were compiled from one file if any single routine from that file is referenced. >Since other linkers are smart enough to include just the desired routine... Actually, since this group is comp.software-eng, I'd like to state my opinion that one function per source file is a good way to go. If multiple functions per source file are useful for a given situation, they should all be strongly related so that if you are planning to use one you would typically use all of them rendering the problem moot. Given the UNIX V.3 shared library facility where only one copy of the routines is needed and is not present in all executables, the desire to limit size of binaries to the minimum has another way of being solved. -- Jerry Carlin (415) 823-2441 {ihnp4,lll-crg,ames,qantel,pyramid}!ptsfa!jmc soon: {ihnp4,lll-crg,ames,qantel,pyramid}!pacbell!ptsfa!jmc To dream the impossible dream. To fight the unbeatable foe.
raveling@vaxa.isi.edu (Paul Raveling) (03/05/88)
In article <4148@ptsfa.UUCP> jmc@ptsfa.UUCP (Jerry Carlin) writes: > >Actually, since this group is comp.software-eng, I'd like to state my >opinion that one function per source file is a good way to go. If multiple >functions per source file are useful for a given situation, they should >all be strongly related so that if you are planning to use one you would >typically use all of them rendering the problem moot. > I believe the best software engineering criterion to use is to organize functions into modules in such a way as to minimize overall complexity. The IBM (Itty Bitty Modules) approach leads to excess complexity and lack of appropriate structure in any but the simplest software. I've worked with two sets of software that used this approach and paid for it in maintainability -- One was OS/360, the other was various MIL spec software, mainly for air data computers. For example, one function per file eliminates the ability to share a set of data among related functions, but to encapsulate it within this set. The biggest maintenance headaches I've encountered have tended to be tracking down accesses to public data. On the other hand, lumping too many functions into the same source file produces the same kind of lack of structure and lack of encapsulation as one function per source file. In my experience the best-organized software probably has averaged 4-6 functions per module, but it's inappropriate to look for a general rule of "n functions per module". Minimizing complexity sometimes DOES dictate one function in many files, but sometimes it may be 10. --------------------- Paul Raveling Raveling@vaxa.isi.edu