[gmx-developers] Future developments

[Berk Hess]

Erik Lindahl wrote:
>
> On Feb 24, 2009, at 2:58 PM, David van der Spoel wrote:
>
>> Erik Lindahl wrote:
>>> Hi,
>>> On Feb 24, 2009, at 1:35 PM, David van der Spoel wrote:
>>>> Hi,
>>>>
>>>> yesterday I put a question on the developer list on where to put a 
>>>> new mini-library for statistics. Right now it is used only from the 
>>>> analysis tools but it might also be used from other parts of the 
>>>> code. Hence I suggested placement in gmxlib, or even directly in 
>>>> src. If no one object I will do this later today.
>>>>
>>>> More in general, we should decide on the future structure of the 
>>>> source tree, do we want a src directory with dozens of 
>>>> subdirectories, or should it be hierarchical. Do we move to one 
>>>> library or do we keep four different ones?
>>> Long-term I'd say we want one library, but with proper namespaces :-)
>>
>> What does that mean in C?
>
> No such thing, unfortunately :-)
>
> I guess we could put them in the main library with names like
>
> gmx_analysis_funroutine()
>
>
>>
>>
>>>> We should also document code recommendations. For instance, Berk 
>>>> stated in another mail recently that we moved to the 4 space 
>>>> indentation etc. We should put this information on the wiki, for 
>>>> everyone (including me) to read.
>> It would be nice to have the recommendations on the wiki anyway. 
>> Should it indeed be the layout as in domdec.c? In that case I will 
>> add it, including a description of abstract code.
>>
>> Since some of us are writing new code even for 4.1, it would be nice 
>> to start using the new rules anyway (I haven't so far).
>
>
> Yes, pretty much, although when I just browsed the 'net I became 
> unsure if this really is "stroustrup" - perhaps more BSD/Allen 
> indentation.
>
> Basically, the important changes we talked about in uppsala last 
> summer was:
>
> 1) Use more spaces so we can tell indendation levels apart. If you are 
> running out of screen space you should use this fancy new feature 
> called "function" ;-)
>
> 2) Put braces on separate lines, in matching columns, and _always_ use 
> braces. The main reason for this was that we all have a tendency to 
> write compact code that's hard to read.
>
> 3) It's nice to use several lines to tell function arguments apart...
And:
4) use spaces iso tabs, such that the layout is independent of any 
environment/program choice.
The strings in the headers turn this on automatically for emacs.

Berk