1) No subroutine should do more than one thing. Even if only one parameter dependent statement needs to be added to let an existing subroutine do what I wanted i refused to do so, and created an almost identical second subroutine.
2) If a variable does something identical on multiple places then it should have the same name on those places. Examples, a loop with loop variable IAA loops over residues, with variable IAT loops over atoms, and with ISOU(P) loops over molecules.
3) Never did clarity have to suffer for speed. Against the time we are fed up with the performance of WHAT IF, newer, two or more times faster computers will be available.
4) To save space, many times local arrays are equivalenced to the common array ESPACE. Never is ESPACE used for communication between routines. Also never will a variable be used for something else as it was originally meant.
5) Where-ever user input is requested this is done via full proof I/O subroutines. This circumvents that FORTRAN crashes when a real is type when an integer was requested. Also on every user-given number a range check is performed, and adequate information is supplied in case of an input error, or in case of impossible input. Also where possible help is given upon just hitting RETURN in case of giving input.
User supplied subroutines that disobay any of the above 5 rules will not be acceptable for me to become an official WHAT IF subroutine.
1) Never change an existing subroutine. You might corrupt future extensions this way. If you want a subroutine to do something else, then just create an extra option (preferably in the SPCIAL menu) which calls a clone of an official WHAT IF routine.
2) Every user added subroutine, function or common block should have its name started with the same three characters which I supplied you with when you got WHAT IF. This way there will never be any name clashes between your subroutines, the official subroutines, or any body elses subroutines.
3) Every subroutine or function should start with the comment block as found in every official subroutine. The lines starting with C.*** (the symbol *** stands for 3 minus signs, but this stupid editor can not do that) can be left out as your own subroutines are of course not subject to the same limitations as the official ones. The lines starting with C**** in the header common block will be copied to the documentation. The lines starting with C.*** will not end up in the documentation. The header common block must start with the line C/// and end with C followed by three back slashes in order for the automatic documentation writing subroutine to be recognized.
4) FUNCTIONS should not have implicit naming. Instead of FUNTION COUNT one should use REAL FUNCTION COUNT eventhough COUNT is already real. My library handler program needs that. Sorry.
5) Although I know that this is difficult, and that it is hard to ask, I would highly appreciate if people would try to write their additions a little bit in the same style as the official subroutines. In case one of your subroutines is interesting enough, and general enough to make it an official subroutine it would make my task easier.
Especially try to use the same naming convention for loop variables. Also try to let all variables at the molecule level have SOU as part of their name, all variables at the residue should contain AA in their name, and variables at the atom level AT.
6) Please leave your full name address, phone number and computer mail address(es) in every subroutine you write. Not only do I prommis to leave them inthere upon redistribution, it also makes it possible for other users to discuss the routines with you without my interference. (I am already busy enough as it is now). 7) Don't use the WIFPAR array for parameter passing. Define your own equivalent array. More general, keep your hands off the existing common blocks.