My programming style

i.e. why I write in UPPER CASE

• I do still write my code in UPPER CASE. I reserve lower case for literal strings, and for comments. I find that sources written that way are more legible, one immediately see what is code and what are comments.
  Sometimes I write in lower case code which is temporary, for debugging.
• Oh yes, I do debugging the old way of inserting WRITE (or write !) statements here and there. I do not use debuggers, since I should learn a different one under each OS I'd work with.
• Of course I use extensive comments, my code is typically 33.33% of comments, 33.33% to deal with error conditions, and 33.33% to do the real work.
• I like the old fixed source format. I start code in column 7 or later, and place a small dot in column 6 to mark continuation lines.
• I start my main programs with a PROGRAM statement
• I declare types and dimensions in the same statement, but use separate DATA statements whenever I have to initialize a variable.
• I use only INTEGER, REAL and DOUBLE PRECISION variables (actually I'm not totally consistent, sometimes a REAL*8 slips in), I mean for normal, working variables.
  I do use the specific forms INTEGER*2 *4 or REAL*4 *8 for variables in external records when I'm forced to do it. This usually means telemetry files I receive from somewhere else. For my files I'd prefer to waste some disk space, but use only default 32-bit (or longer) quantities.
• Of course I use also LOGICAL (tout court) and CHARACTER*n.
• I do use the EQUIVALENCE statement (also with characters). It is an handy way to deal with external telemetry records.
• I use CHARACTER[*1] to store byte numeric quantities, when I'm forced to use them (and CHAR and ICHAR to convert them to numbers for any arithmetics, it is perhaps inefficient but portable).
• I do use COMMON blocks (almost always in INCLUDE files) to exchange global data with subroutines avoiding long argument lists.
• I do use INCLUDE files also to define PARAMETER constants, and, occasionally, to link some subroutines in more than one program while I am developing them (later I move them to a library), or even some pieces of code before I make a subroutine out of it.
• I do not use the IMPLICIT NONE statement, because once it was not portable. I use instead equivalent compiler options (like -u) to force the same effect, and declare all variables.
  I waive full declarations for old, tested code, or for simple code where the good old I-N rule is safe.
• I do not indent code, except for the body of long IF THEN ELSE ENDIF nested blocks. Complex indentation means hard to read.
• I do use numeric labels with DO loops. They make code more legible, one immediately knows where a loop ends.
  I do not use DO ENDDO (except rarely for very short loops, 2-3 lines max).
• I am not afraid of using GOTO. It is useful for undefined loops (I can never remember the difference between a do while and a repeat until, while with a GOTO I know exactly what I am doing), and for error branching.
• I also find useful the computed GOTO, typically as dispatcher for actions controlled by a numeric opcode.
• Of course I use only CONTINUE statement to hold labels (do loop end or go to target).
• I sometimes use alternate return from subroutines, I find it is a more legible way of doing error handling.
• I do terminate my routines with RETURN and my programs with STOP (actually I never use STOP but a call to a Z_EXIT routine of my own, but that is a different story). I believe it is more legible and more correct to separate the termination (runtime executable) statement, from the END which is just there to tell the compiler a program unit is finished.