[gmx-developers] Re: abstract type convention

Mark Abraham mark.j.abraham at gmail.com
Tue Jun 11 08:39:44 CEST 2013


On Jun 10, 2013 3:22 PM, "Erik Lindahl" <erik.lindahl at scilifelab.se> wrote:
>
> 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!

All seems good to me.

> 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 :-)

Hey, I used my first terminal thirty years ago, and it had 40 columns and
64k memory! It was a decade before I used a bigger one. :-) Also, if you
have the brain cells to remember the unique three-character sequence of
that function name, then you are clearly not working hard enough! But the
principle is sound! :-)

Mark

>
>
> Cheers,
>
> Erik
>
>
>
>
>
>
>
>
> --
> gmx-developers mailing list
> gmx-developers at gromacs.org
> http://lists.gromacs.org/mailman/listinfo/gmx-developers
> Please don't post (un)subscribe requests to the list. Use the
> www interface or send it to gmx-developers-request at gromacs.org.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://maillist.sys.kth.se/pipermail/gromacs.org_gmx-developers/attachments/20130611/4be2a386/attachment.html>


More information about the gromacs.org_gmx-developers mailing list