Topic: Best strategy for source file structure?

Three strategies :

(1)  Only one source file for a project.
       Main program and all subroutines in the same file.

(2)  Multiple source files for a project.
       Multiple subroutines in each source file.
       Perhaps grouped together by subject relevance.

(3)  Separate source files for main program and every subroutine.


Are there any more?

I think (1) is a poor strategy to use.
I tend to use (2) but I've been thinking for a long while that it would have been better to use (3).

What do others say?
---
John

  • xbits
  • New member
  • Offline

Re: Best strategy for source file structure?

Hi, John...

In reply to your question, I am not sure that the IS ONLY ONE answer.  Doesn't the strategy
depend in great part on the characteristics of the incoming work flow?  For example, compare
the programming requirements for a utility company which does the same thing day after day
for years at a time, with those of a software firm that produces quick responses to a variety
of requests that bear some similarity.

In the first case, the programs are likely to remain static for long periods.  In the second, the
programmer has a short turnaround time to produce program(s) which are likely similar to
the stuff he did 2 or 3 months ago.

So, in one case there is no need for variety and speed, but in the other it requires that the code
be easy to get at and easy to modify -- and right under your nose.

Re: Best strategy for source file structure?

Thanks for the reply.  I think you're right.
I've been using strategy (2) but I was considering changing to strategy (3) because it's sometimes hard to remember where everything is.

See also my new post today under, 'Keeping track of current subprogram whilst editing'.
---
John

Re: Best strategy for source file structure?

I would say the easy answer is "it depends".  It truly depends on the size of your project.

With our recent project of over 200 modules, it would be totally unwieldy to do either (1) or (3).  Using (2), you have the option of grouping like "routines" in modules so that they could be easily used by other projects, for example.  Or having a structure so that the modules look similar (certain kinds of routines in each module).

For very small projects, I usually choose option 1.  I probably would never choose option 3.

-----
Linda

Re: Best strategy for source file structure?

First, we should think about the  "module" feature. Indeed, "Perhaps grouped together by subject relevance" has a strong link with modules. However, and unfortunately, only one compiler implements the "sub-module" F2008 feature : the Cray compiler (AFAIK). This usually leads to either big modules (when the programmer wants to hide some internal things, declaring them as "private") or many chained modules (but in this case, it is not possible to declare as "private" some structure fields -- e.g. components of a derived type -- which must be used by other modules of the same developper). In my numerical library MUESLI, I chose to split the big module into several small modules and got hidden things for the user by compiling twice the modules' chain: the first time from the first module to the last and the second time in the reverse direction, storing the created MOD files in two separated folders (ok, it's a bit difficult to explain in one sentence).

Second, a practical remark: I prefer to distinguish "physical file sources" from "logical units". IMHO, each source file should not be longer than, let's say, few hundred lines. In that case, we can use the "include" facility of F90 (or even the "#include" preprocessing command) to split the routines of a big module in separated physical files.

  • xbits
  • New member
  • Offline

Re: Best strategy for source file structure?

Hello to All...

It's a bit late for more comments on this subject, but I was rereading this stuff and remembered a technique that I used some time ago. 

I built "index" modules which contained nothing but INCLUDE statements, each with any necessary verbal descriptions as comments.  Most of the includes were commented out, however.  If I needed a particular module, it was easy to look at the descriptions, and uncomment the associated INCLUDE.  I seldom had to search for anything.

You can even make overlapping modules, with some common routines present in 2 or more "index" modules, as needed.

I once worked with a guy who was a believer in keeping ALL of his subroutines in his "MASTER" program.  Over time, the thing approached unmanagable size, and was difficult for an outsider to follow, since so much code was irrelevant.  So, one of the
criteria that is involved in the structuring of source files is "Who is going to maintain the code after I'm gone?"

Re: Best strategy for source file structure?

These comments on this subject have appeared on LinkedIn:

Arjen Markus
consultant at Deltares (former name: WL|Delft Hydraulics)
https://www.linkedin.com/groups?viewMem … ID=4046922

8000 lines or 40 files are not all that much, as far as I am concerned, but since you find it hard to cope with, I will try to give you at least some suggestions:
- Make sure you store the sources and build scripts in a version control system. Probably best after rearranging the files. There is a wide choice of VCS's nowadays.
- Make sure you have one or more Makefiles/Solutions+project files/whatever is appropriate for your development environment, so that building the program is started merely by pressing a button in the IDE or typing a single command.
- You can probably divide the sources in separate directories, grouped logically according to the nature of the code. That will reduce the clutter.
- You may consider putting several source files into one, but I would do that only if they are related strongly enough, not just for the purpose of reducing the number of files.
- Make sure the files have relevant names, so that you can easily recognise them.

But, perhaps most practical of all, get to know the contents of these source files, so that you can easily find the one you need.

------------

Jouni Karjalainen
PhD student at University of Oulu/Dept. of Physics
https://www.linkedin.com/groups?viewMem … D=14139594

I agree 100 % to what Arjen Markus wrote. My current project is roughly double the size with about 110 files and 17000 lines of code, excluding libraries written by others. I do not consider it large at all.

I use CVS for version control and GNU Autotools for the build process etc. but there are probably more sophisticated, modern or simpler options available.

I would not recommend using 'include' for adding regular subroutines. In case you want to separate the implementation from the interface, a better way is to define the interfaces in modules and use separate source files for the implementations. Possibly you could move the implementations to a separate folder/folders if desired? That may slightly complicate the compilation/build, though.