abmg@cathedral.cerc.wvu.wvnet.edu (Aliasghar Babadi) (05/04/91)
Hi, I have some questions regarding software organization: 1- What is a module and how do you describe it? 2- What is the best way of organizing your code? 3- Is it a good practice to keep each function in a seperate file? 4- And what more would you like to say about this subject? Thank you for your sugestions and comments.
sarima@tdatirv.UUCP (Stanley Friesen) (05/05/91)
In article <1684@babcock.cerc.wvu.wvnet.edu> abmg@cathedral.cerc.wvu.wvnet.edu (Aliasghar Babadi) writes: >Hi, > I have some questions regarding software organization: > > 1- What is a module and how do you describe it? A module is a group of closely related routines and the data associated with them. I tend to use a rather object oriented view, where the data set is central, and the module contains all routines authorized to operate on it. > 2- What is the best way of organizing your code? Generally, I create sets of routines that cooperate to manage a resource or provide a service. I make an effort to make all variables have the smallest scope usable. That is, when writing in C, I use function scope where possible, then I switch to file local scope, and only go to true globals if I cannot find a way to access the data reasonably at file scope. I apply the same criteria to routines. I only export the public inteface routines, the others are given local scope. > 3- Is it a good practice to keep each function in a seperate file? Only if writing a large general purpose subroutine library. Otherwise a form of function decomposition is more useful. That is in most cases I place one module per source file. But, if the module is particularly large, I may split it into two or three files on the basis of some subset of the functionality. -- --------------- uunet!tdatirv!sarima (Stanley Friesen)
iverson@xstor.com (Tim Iverson) (05/07/91)
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