Changes between Version 34 and Version 35 of HowTo/FortranStandards


Ignore:
Timestamp:
2013-06-25T13:34:02+02:00 (11 years ago)
Author:
jgipsl
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • HowTo/FortranStandards

    v34 v35  
    9494> JP : Always use the INTENT and DIMENSION arguments in the declaration. This helps readability and allows the compiler to do consistency checks. 
    9595 
     96 
    9697{{{ 
    9798 
    … …  
    118119 
    119120> JP: Loop labels remind me too much of FORTRAN 4 and GOTO statements :-) 
    120  
     121>> JG : I agree with Jan... 
    121122[[BR]]  
    122123 
    … …  
    138139NOTE: The emacs indent function works well for this, since it indents with spaces (even if you use the tab key). 
    139140 
    140 (6) '''Document units:''' Use comment lines to document units and unit conversions 
    141  
    142 (7) '''Document your thinking:''' Document your thinking rather than simply the describing the fortran code in  
    143  
     141> JG : don't add a single comment character on an empty line, keep the line empty. Do not : 
     142{{{ 
     143! 
     144}}} 
     145  
     146(6) JG : Always add '''IMPOSE NONE''', in beginning of subroutine or module.[[BR]] 
     147 
     148(7) JG : Always use captial letters for key words. ALLOCATE, SUBROUTINE, DO, END DO,...[[BR]] 
     149 
     150(8) JG : As JP said, always use INTENT() for arguments.  
     151 
     152(9) '''Document units:''' Use comment lines to document units and unit conversions  
     153  
     154(10) '''Document your thinking:''' Document your thinking rather than simply the describing the fortran code in   
    144155---- 
    145156 
    … …  
    181192'''IF''' bavard '''>=''' 3 then input parameters to major subroutines are reported  
    182193[[BR]]  
    183  
    184 (2) '''personal debug flags:''' 
    185194 
    186195(2) '''Don't forget the ELSE:''' If you are using an IF...ELSEIF....ENDIF loop, always make sure you include an ELSE statement at the end to catch any situation not covered in the other cases.  This should be done even if the ELSE statement doesn't do anything, just so that other people know that nothing needs to be done in some cases.  Too many bugs are found because an IF statement is not triggered due to something the programmer didn't think of.  This is especially problematic when the  programmer thinks to him/herself, "This value will always be in this range, so I don't have to consider other possibilities"...and then one day things change. 
    … …  
    201210 
    202211> MJM: if nothing is done in the ELSE, it could have something written in a comment instead.  As long as it is clear that the programmer has thought of the possibility that the loop is not triggered, it's fine by me. 
    203   
     212 
     213> JG : Do not agree. The developer should always think. I don't think this will not leed to less bugs. 
     214 
    204215> JP : Yes IF statement always should have an ELSE ... even only for a comment saying we should never be here. Even better is a call to ipslerr to stop the code and shay we should not have been here. 
    205  
    206 [[BR]]  
     216>> JG : I agree for call  to ipslerr if it is a useful test.  
     217[[BR]]  
     218 
     219 
    207220 
    208221(3) '''Don't stick to one compiler:''' No compiler will catch all your bugs.  Always use multiple compilers to check, including all the error flags.  For example, I first compile locally with " gfortran -c -cpp -O0 -pg -g -Wall -ffpe-trap=invalid,zero -fbacktrace -fcheck=all -fbounds-check -pedantic".  Then I compile on asterix with "ifort -c -cpp -g -O0 -debug -fpe0 -ftrapuv -traceback".  I'm hoping to do it on Curie soon, too, since they have the NAG compiler there which is good with error checking.  Finally, running the code through valgrind will catch every single piece of memory that you use without initilizing it (apart from some extreme cases), more thoroughly than a compiler.  "valgrind -v --track-origins=yes ../../../bin/orchidee_ol".  This is very slow, but a nice check.  There are some errors in the NetCDF calling routines that I haven't tracked down, but all the DOFOCO code has been cleaned. 
    … …  
    229242 
    230243> JP : A rigid module structure forces us to think ahead of development about the tasks reserved to each module and what information needs to be exchanged with other modules. This might sound like a pain as it makes "small fixes" difficult but it contributes in my mind to the clarity and modularity of the code. Planing model structure before development is a very healthy exercise we need to encourage that. We have the Group de Projet to do this now. 
     244[[BR]] 
     245[[BR]] 
     246> JG : I do not agree about putting all files in the same directory. We can make new src_ directories if it is needed.  
     247 
    231248 
    232249= Points to Discuss (as recommended by Philippe) = 
    … …  
    238255 
    239256> JP : I would be in favour of using structures for the infrastructure variables and thus shorten the argument list. USE statements should also be there to provide tools to the module (interpolation routines, IO routines, ...). No variable should be exchanged with a USE statement.  
     257 
     258> JG : shared module variables is ok for parameters, dimensions variables that are calculated in the beginning and do not change during run time (kjpindex for exemple). Not ok for prognostic variables. 
     259 
    240260 
    241261[[BR]]