Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!ames!ucsd!sdcsvax!ucsdhub!hp-sdd!hplabs!sdcrdcf!trwrb!aero!venera.isi.edu!raveling From: raveling@vaxa.isi.edu (Paul Raveling) Newsgroups: comp.software-eng Subject: Re: Configuration Management (UNIX Linker) Message-ID: <4957@venera.isi.edu> Date: 5 Mar 88 03:26:29 GMT References: <5303@well.UUCP> <4148@ptsfa.UUCP> Sender: daemon@venera.isi.edu Reply-To: raveling@vaxa.isi.edu.UUCP (Paul Raveling) Organization: USC-Information Sciences Institute Lines: 39 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