I'm trying to write a script which will safely and repeatedly rename the source code files wherever there may be two files whose names differ only in case, and automatically update the references to those names inside the source code. My intention is to post this script once it's working for the benefit of anyone wishing to use it.

There is some logic to the naming convention currently used and I would like, if at all possible, to use an alternative naming convention which follows the same logic. However, I'm getting a bit confused about even the current naming convention. If anyone could explain it to me I'd be very grateful.

Specifically, here is what I *think* is the case right now:

Standard extensions .C and .H :- the former for historical reasons and the latter to distinguish between system files and FOAM files (suggest change .C -> .cpp and filename.H -> filenameF.h)

Class definitions are mostly in files which match the pattern [A-Z]*.H

exceptions are pointPatchField.H, dictionary.H and vector.H (although the latter has class definitions which are not the same as the filename)

I'm limiting myself here to filenames that result in duplicate names in a case-insensitive environment - there are other exceptions such as files whose names begin with a variable name or an algorithm name which begins with a capital letter (e.g. UEqn.H, YEqn.H).

then again, sigQuit.C is a .C file that contains a class definition for sigQuit - why is this a .C file and not a .H file?

Does anyone have a summary of the present naming convention or should I just continue trying to figure it out by myself?

- files have the name of the class they define.
- Classes start with uppercase if they are templated, lowercase if they are non-templated (though this is not yet fully consistent)
- .C, .H to denote C++ code.
- the sigQuit.C could be split into a .H file (class definition) and .C file (static variable) but since the class gets used nowhere else we haven't bothered. Same for sigInt.C etc.

Reading through the gcc documentation it seems that .H is equivalent to .hh which is c++ specific, so how would you feel about a global rename of .C -> .cpp and .H -> .hh?

I was writing a bash script to do this - rename the files for a case-insensitive environment and edit the code accordingly to reflect the changes - in order to be able, down the track, to produce a version that will run on windows. In doing so I set up a cross-compiler which might get around the case sensitivity problem - compile on linux and deploy on windows. Still, a file naming convention that works everywhere might still be beneficial don't you think?

I am observing this discussion with a growing interest as I am supposed to use OpenFOAM under Windows some day. Till now I was just staying aside not really actively joining the debate but as time goes and my need for Windows port is more and more urgent I would like to drop few cents into discussion here that touches some formal problems as well. I have to point out, that I my point of interest to OpenFOAM is merely software engineering at this time.

Naming conventions:

Do we have some document that describes the used naming conventions so anybody can enforce them in its code? It will be beneficial for all sides...

Extensions:

I am not sure if it was a good idea to use a .C and .H as C++ file extensions. There are systems who are case insensitive and this extension says nothing more about the code. There are normaly used extensions .cpp, .cc, .cxx for C++ source files, .h, .hh, .hxx for C++ header files and .ihh, inl for C++ inline files. These are most used not for the fun, but they simplify the first contact with code.

Filenames:

Common practise has acknowledge that it is wise to name the file exactly as the class hidden inside. Java is quite nice example as it is even enforcing it. Nobody has a problem to look up any piece of code. You should reconsider it if there are inconsistences they should be fixed. To use a lower and upper case to differentiate between a template and non-templated code is hard to see especially in the case of case insensitive systems (not only Windows) and brings no help, not really.

Namespaces:

I do not know how exactly are adpoted namespaces in OpenFOAM but why not to let namespaces correspond with a directory structure? Namespace can express a general conceptual connection between classes and makes all the stuff more clear. If connected with directory structure it is very comfortable to search through the code. I am afraid it is little bit late now, but the first contact with OpenFOAM code could be more gentle.

It was just few ideas that a lot of people get on the first look at OpenFOAM code...