Re: amber-developers: Undocumented namelist variables

From: Robert Duke <rduke.email.unc.edu>
Date: Thu, 9 Mar 2006 13:29:50 -0700

Okay, but I frequently comment out debugging-related writes, leaving them
in
place should they be useful later (or sometimes I have an obvious ifdef,
including DBG somewhere in the name). I would like to be able to retain
such mechanisms, and consider them okay myself, as long as it is clear in
comments that the stuff supports debugging only (and as such, it IS
possible
that they will be obsolete - but they should never be left activated in
the
product anyway). We could probably develop some debugging standards for
this sort of thing; trouble is the general fortran "this is a debug line"
convention turns all the debugging on, as would any specific define.
Regards - Bob

----- Original Message -----
From: "David A. Case" <case.scripps.edu>
To: <amber-developers.scripps.edu>
Sent: Thursday, March 09, 2006 3:20 PM
Subject: amber-developers: Undocumented namelist variables


> On Thu, Mar 09, 2006, David A. Case wrote:
>
>> From: Scott Brozell <sbrozell.scripps.edu>
>
>> In 8 there was an undocumented pb namelist variable nsaa.
>> In 9 there is an undocumented pb namelist variable maxarc.
>
> This is a tough call, and I have not been consistent in the past. One
the
> one hand, having undocumented options is attractive to developers. But
it
> has turned out the users try them anyway, future developers are confused
> by them, and those options often become broken by future code changes,
> because
> they are not being tested.
>
> So the new policy is: no undocumented namelist variables. (Scott's
> "retired"
> varaibles are OK: they stop execution with an informative error
message.)
> If you need local variables for your personal work, make a CVS branch.
>
> [As with everything, exceptions may be granted, but I think this is the
> correct general rule. A corollary is: don't leave "commented out" or
> "ifdef-ed out" stuff in the code. Such stuff is as likely to be
confusing
> as
> helpful, and "turning it back on" may break things since the code has
> evolved
> since it was originally written.]
>
> We'll try to get the above rules implemented as much as possible by the
> time Amber 9 comes out.
>
> ...thx...dac
>
Received on Wed Apr 05 2006 - 23:49:40 PDT
Custom Search