[AMBER-Developers] Amber coding standards

From: Joe Krahn <krahn.niehs.nih.gov>
Date: Mon, 16 Mar 2009 16:03:42 +0000

I was looking at "Amber coding guidelines" on the wiki and noticed that
many source files do not follow the syntax. Maybe the wiki needs some
updating, and probably some of the source files as well.

In particular, many source files have lines longer than 80 chars, and
there are many instances of using // to join long strings rather than
using & to break a single string literal, and many have lines longer
than 80 characters. One reason to avoid // is that cpp may interpret
them as a C++ comment. I assume that this is not really a problem, so
using // to join strings is safe, even though it should not be used to
break string literals.

I generally try to follow strict Fortran95, but there are obviously a
few extension routines that are OK to use, such as GETARG. It would be
nice to have a list of these.

Also, the Amber9Forum section on "automatic vs allocated arrays" is not
exactly right. First, the pointer array needs the SAVE attribute to
ensure that the allocation is saved between calls. Second, it is better
to use an allocatable array rather than a pointer array. Pointer arrays
can sometime be much slower because pointers can be aliased, making some
vectorizations unsafe. For a local pointer, the compiler may or may not
be smart enough to assume no aliasing. Also, allocatable arrays are
always initialized as unallocated, so there is no need for the
'first_call' flag. This might simplify some of the start-up code to
avoid memory leaks with multiple calls to SANDER.


AMBER-Developers mailing list
Received on Wed Mar 18 2009 - 01:09:44 PDT
Custom Search