Xref: utzoo comp.software-eng:2556 comp.misc:7523
Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!usc!apple!rutgers!att!dptg!pegasus!dmt
From: dmt@pegasus.ATT.COM (Dave Tutelman)
Newsgroups: comp.software-eng,comp.misc
Subject: Re: Coding standards (was Re: Programmer productivity)
Summary: There IS a reason, but not overwhelming
Keywords: One function per file?
Message-ID: <4290@pegasus.ATT.COM>
Date: 30 Nov 89 14:24:56 GMT
References: <Nov.18.22.47.26.1989.9685@paul.rutgers.edu> <34796@regenmeister.uucp> <2226@jato.Jpl.Nasa.Gov> <128179@sun.Eng.Sun.COM> <546@sagpd1.UUCP> <4727@netcom.UUCP>
Reply-To: dmt@pegasus.ATT.COM (Dave Tutelman)
Distribution: na
Organization: AT&T Bell Labs - Lincroft, NJ
Lines: 73

In article <4727@netcom.UUCP> hue@netcom.UUCP (Jonathan Hue ) writes:
>>In article <??> dopey@sun.UUCP (Can't ya tell by the name) writes:
>>>(e.g. IMHO a. few if any globals, b. one routine per file...
>
>(Following assumes programming in C)
>
>My $0.02: I don't agree with (b) at all.  In practice, (a) and (b) are
>often mutually exclusive.  Sometimes two or more functions will need to
>use the same variable, and if you can shove the functions that use it in
>one file and make the variable static, you save polluting your program's
>global name space.  
	I'm glad you posted that; I was thinking of doing so.  Right on!

>I suggested using tags...
	Ditto!

>.... but since he used Microsoft Word on a Mac to edit programs, tags
>weren't very useful.
	I have a similar problem, in that most of my editors on the PC
	don't support tags, but I use "stevie" when I need tags on the PC.
	I also use "cpr" to generate function indices in my hard copy.

There IS one argument, in some cases a compelling one, for "one function
per file".  In general, linkers aren't smart enough to link just
PART of a binary file (.OBJ or .o), when that file contains a function
needed by the link.  Consider, therefore, developing a library of functions
to be used by several programs.  For instance, consider a library that
manipulates a widget, and can open, close, bump, and bash the widget.

As Jonathan correctly notes, these functions are likely to share a
set of "limited global data" about the widget, private to the outside
but public among open(), close(), bump(), and bash() of widget.
So we are tempted to write the four functions in a single C file, and
declare the limited-globals as "static".

However, suppose the library will be used by an application that:
   1.	Has strict memory constraints, and
   2.	The only thing it does to the widget is "bash()" it.
The linker wouldn't be able to separate out the bash() function from
the binary file, and the application would carry the memory burden
of all the widget functions.

The alternative is to put each of the the four public widget functions
in its own file, compiling to its own binary, and use a librarian
program to combine them into a library file.  Decent linkers can
easily link part of a library file, in quanta of the original object
files.

How do we deal with the shared data?  There are two ways, one ugly
and one clean (but more effort, and a little bigger which partially
offsets the memory savings):
   -	UGLY: pollute the global data space, and choose names not
	likely to be used by the application (like "widg_lib_firstone").
   -	HARDER: write a "data-manager" function, in yet another file,
	which owns the static variables and responds to requests for
	them from the library function.  The variable names can be
	translated into integers through a header file common to the
	library functions.  The only pollution of the global name
	space is the name of the data manager for widget data.  So
	calls would look like:
		firstone = widg_lib_datamgr( GET, FIRSTONE );
		error    = widg_lib_datamgr( SET, FIRSTONE, firstone );

I've occasionally had to write libraries where this sort of thing
was important.

Hope this helps.
+---------------------------------------------------------------+
|    Dave Tutelman						|
|    Physical - AT&T Bell Labs  -  Lincroft, NJ			|
|    Logical -  ...att!pegasus!dmt				|
|    Audible -  (201) 576 2194					|
+---------------------------------------------------------------+


Brought to you by Super Global Mega Corp .com