[gmx-developers] Future developments

[Erik Lindahl]

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...



Cheers,

Erik

------------
Erik Lindahl   <lindahl at cbr.su.se>  Backup: <erik.lindahl at gmail.com>
Associate Professor, Computational Structural Biology
Center for Biomembrane Research, Dept. Biochemistry & Biophysics
Stockholm University, SE-106 91 Stockholm, Sweden
Tel: +46(0)8164675  Mobile: +46(0)703844534  Fax: mail a PDF instead