- General rules for good programming
- General notation convention
General rules for good programming¶
Header in every routine¶Each routine should start with a header. This header (comments) should contain following information:
- brief description of what is done in this routine
- parent-routine (which routine calls this function)
- information of major changes, the responsible developer and the date of modification
The header should be formatted as follows:
subroutine set_tracer_position() !=================================================================== ! This routine is used to set the initial position of the tracer ! ! Called from celset (setup.F90) ! ! Description Programmer Date ! ------------------------------------------------------------------ ! Original version..................................DE 2007-10-25 ! !===================================================================
Passing arguments to functions and subroutines¶Every argument of a routine must be clearly declared by
intentstatements to declare how the argument is used:
intent(in): argument is just submitted to the routine; this value will not be modified by the routine
intent(out): argument is initialized by the routine and submitted to the parent-routine.
indent(inout): combination of both
Furthermore, every argument should be briefly described - if possible in the same line where it is declared, e.g.:
subroutine place_spheroid(mid,rad,objid,prior,num,matc) use ptool_interface use mod_isale, only : nx,ny,nz implicit none real*8, intent(in) :: mid(1:3) ! midpoint of spheroid real*8, intent(in) :: rad(1:3) ! radius of spheroid integer, intent(in) :: objid ! object ID assigned to cells integer, intent(in) :: num ! upper bound of 'prior' integer, intent(in) :: prior(1:num) ! priority list integer, intent(inout) :: matc(1:nx,1:ny,1:nz) ! array of object ID's
Notation for comments¶
Use comments whenever possible. If you want to show that a specific comment is made by you, you should add your initials right after the '
!DE we might rearrange this routine later to obtain better performance
Critical comments (mostly used as reminder for developers) should start with '
relic' to ease identification of 'critical' parts in the code, e.g.
!DErelic note that these parameters are hardcoded - move them into asteroid.inp later...
Use interfaces or interface-procedures whenever possible¶
Avoid antiquated f77-features¶
- goto constructs
Advices for platform- and compiler-dependent developments (differences between gfortran-, ifort- and g95-syntax)¶
General notation convention¶
Variables are always lower case, constants are always uppercase (this means also variables treated as constants).
Important variables used in both codes¶
|i||index in x-direction|
|j||index in y-direction|
|k||index in z-direction (not used in 2D to avoid confusion)|
|l||index of material|
|cc|| pointer to current cell (
|mm|| pointer to current material (
|oo|| pointer to current object (e.g. projectile,
|ll|| pointer to current layer-structure (
Mesh indices and domain decomposition parameters¶
|nx,ny,nz||number of cells in x/y/z-direction (outdated; better use n(X),n(Y),n(z) instead)|
|nxp,nyp,nzp||number of grid points in each direction (=nx+1,ny+1,nz+1)|
|is,js,ks||start of local grid (domain dependent; =1 for serial jobs)|
|ie,je,ke||end of local grid (domain dependent; =nxp,nyp,nzp for serial jobs)|
|ipe,jpe,kpe||end of local grid including ghostpoints (domain dependent)|