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.

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?"

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.

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.

See also my new post today under, 'Keeping track of current subprogram whilst editing'.
---
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.

(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