Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!samsung!uunet!xstor!iverson
From: iverson@xstor.com (Tim Iverson)
Newsgroups: comp.unix.misc
Subject: Re: software organization
Keywords: software module organization function
Message-ID: <1991May07.023322.798@xstor.com>
Date: 7 May 91 02:33:22 GMT
References: <1684@babcock.cerc.wvu.wvnet.edu>
Reply-To: iverson@xstor.com
Organization: Storage Dimensions, Inc.
Lines: 45

In article <1684@babcock.cerc.wvu.wvnet.edu> abmg@cathedral.cerc.wvu.wvnet.edu (Aliasghar Babadi) writes:
>	1- What is a module and how do you describe it?

Traditionally, a module has been defined has the set of functions necessary
to implement a single abstract type or a single service.  Popularly, a
module is defined as the source or object file that provides the service.
In actuality, most people usually mean both (more or less).

>	2- What is the best way of organizing your code?

Organize it to achieve your goals and abide by the implementation
constraints.  Typical goals are portable, readable, fast, small, elegant,
simple, etc..  Typical constraints are language, OS, hardware, budget (time
and $$), existing and proposed standards, etc..

Your question seems to beg for a response on the order of 'use no global
variables and put one object (oop object, not object code :-) in each file',
but that kind of knee-jerk response will only serve you in a rather small
static environment, and will soon make your coding style obsolete.

However, if you make your method sufficiently general, it should be useful
it almost all cases.  I like aphorisms, so I use several when coding:  one
step at a time: generalize, compromise, optimize; think big, start small;
whitespace is elegant; etc., etc..

>	3- Is it a good practice to keep each function in a seperate file?

If you're building an object code library (e.g. libc.a for Unix cc), it is
useful to make your object files has small as possible, but no smaller; i.e.
each object file should include (or reference) only data/code actually used
to support a single globally referenced function. If you follow this guide,
users of your library will rarely link in code that is never used - the
stdio library is a bad example of this, the string library is a good one.

For other, less specialized purposes, create one module for each
sufficiently decomposed node in your design diagrams and you probably won't
go wrong.

>	4- And what more would you like to say about this subject?

These questions seem to be fairly pointed; what's the motive behind them?


- Tim Iverson
  iverson@xstor.com -/- uunet!xstor!iverson