Appendix G: Collaborative Development

Any programmers interested in adding new or improved features and functionality into FIT2D are welcome to contact me. Extra manpower is always useful. FIT2D may well provide a good framework for your data analysis developments e.g. An environment of file input/output and data display already exists together with facilities to allow definition and execution of macros. Such added code would remain the copyright of the author(s), but the author(s) would have to accept the distribution of the code under the same conditions as given in Appendices E and F.

Such code would need to follow a number of general guidelines which are necessary in order to maintain the integrity of FIT2D i.e. prevent one part of the program corrupting another part:

• In order to make memory corruption as difficult as possible, all code (or almost all code) should be in FORTRAN-77 with only a few generally available extensions (or hopefully soon Fortran-90) and be able to be compiled with array bound checking i.e. with the -C option for Unix Fortran compilers or the CHECKS=ALL option for the VMS Fortran compiler. All code should be tested and run with array bound checking enabled.

• Use of unconstrained pointers should be non-existent or almost non-existent. At present unconstrained pointers are necessary to allow dynamic memory allocation, but with Fortran-90 this need will disappear. (When this exception there is only one point in the whole of FIT2D where unconstrained pointers are useful.)

• All code should include ``defensive programming'' code to protect as much as possible against mis-use of the code. The last argument of every routine must be the status return variable. On input this variable must be checked to correspond to the ``good status'' value. If not routines must call the subroutine ST_SAVE to report the apparent bad status, and then immediately return. All possible input arguments should be checked for allowed values. If values are not appropriate the error condition should be reported through the status value and a call to ST_SAVE. After an error condition has been found in one of the input arguments all routines must return without any further action. Very low level repeatedly calls routines may be allowed not to include this ``defensive programming'' code when appropriate, provided higher level calls can filter all possible mis-use. (Examples and templates of use of the system can be supplied.)

• When Fortran-90 becomes generally available for the main target machines it will be additionally required to provide an ``interface'' for each subroutine and function.

• All code should be well documented, preferably in the standard style of FIT2D. Templates can be supplied. (An automatic documentation extraction program exists for code following a well defined structure.)

• Programmers are strongly encouraged to follow the following conventions for typing the names of variables, constants, arrays, functions and subroutine calls:
  • Scalar constants: First letter upper case, followed by lower case only
  • Scalar variables: Lower case only
  • Arrays: Upper case only
  • Function calls: First letter upper case, followed by lower case
  • Subroutine calls: Upper case only
  • Fortran function keywords: First letter upper case, followed by lower case
  • Pointers: Lower case p followed immediately by all upper case

  Use of these conventions makes understanding the program and program structure much easier, and may allow automatic identification and processing of particular elements e.g. pointers.

• Interfacing to POSIX 1003.1 operating system functions may use "C", but this should be made immediately callable by Fortran, taking into account both Fortran compilers which add underscores to the end of external symbols, and those which do not. Similarly the different handling of characters strings between Fortran and "C" must be foreseen.