[gmx-developers] Re: abstract type convention

[Erik Lindahl]

Hi,

On Jun 10, 2013, at 2:54 PM, Berk Hess <hess at kth.se> wrote:
> 
> In C++ we should certainly ditch the gmx_ prefix.
> In C as well in 5.0, as all C code should be hidden behind a C++ api, I suppose.

Note that I think we decided we should write out namespaces explicitly, so I assume one would actually write something like

gmx::module::submodule::procedure()

for parts that are C, I think it makes a lot of sense that the equivalent naming is

gmxModuleSubmoduleProcedure()

Whether we then use sub-namespaces or just separate modules with names, or even underscores instead of camelCames seems much less critical. 

The advantage of both of the above alternative is that it is both clear where in the code this procedure or datatype is defined, and since we tend to use prodecure names like "UpdateXYZ()", I also think it's a whole lot clearer what we are updating in this case.  When we use external libraries it is also very clear what names belong to Gromacs and which ones are external. Basically: can we find a scheme where functions and data-types are more self-documenting? I.e., I want it to be clearer what we are doing when we _use_ a datatype/function, rather than having to go to the declaration and hoping there is good documentation for a short acronym name there!

And yes, that means I prefer a hypothetical long name like "gmxInteractionElectrostaticsPMEReciprocalEvaluate()" over "do_pme()". I can type both names in 3 letters and then hitting tab. The world moved away from 80-char-terminals some 30 years ago :-)


Cheers,

Erik