[Rd] Fortran coding standards

[Martin Maechler]

Hi Vivek,

>>>>> "Vivek" == Vivek Rao <rvivekrao at yahoo.com>
>>>>>     on Wed, 11 Apr 2007 06:20:21 -0700 (PDT) writes:

    Vivek> I have some comments on the Fortran code in the
    Vivek> fseries package in file 4A-GarchModelling.f ,

this is "fSeries" {and case does matter in R - contrary to Fortran :-)}
a CRAN-contributed package which has a well-defined maintainer 
whom you can quickly find using

  packageDescription("fSeries")

Further, he might not read R-devel on a regular basis at all ..

    Vivek> especially the subroutine GARCHFIT and function
    Vivek> DSNORM.
    Vivek> I appended the code to the end of an earlier message,
    Vivek> but it was rejected by some rule. 

you (i.e. your mailer) must have used an unspecified binary
mime-type; do use  "text/plain" instead  and the attachments
won't be filtered.

    Vivek> Let me first say that I am grateful that packages for
    Vivek> financial econometrics exist in R.

    Vivek> Fortran 77 had PARAMETERs, and PARAMETERs equal to
    Vivek> 99999 and 200 should have been defined instead of
    Vivek> repeatedly using "magic numbers". More importantly,
    Vivek> the code will fail if NN exceeds 99999, but the code
    Vivek> does not check for this. I hope someone will fix this.

    Vivek> In the code dsged the variables half, one, two should
    Vivek> be made parameters, and instead of 

    Vivek> IMPLICIT DOUBLE PRECISION (A-H, O-Z)

    Vivek> IMPLICIT NONE 

    Vivek> should be used and all variables declared. Although
    Vivek> IMPLICIT NONE is not standard Fortran 77, it is
    Vivek> standard Fortran 90 and is supported by g77.
    Vivek> Experienced Fortranners know that IMPLICIT NONE
    Vivek> catches errors. Another defect is the use of specific
    Vivek> intrinsic functions such as DSQRT. There is no need to
    Vivek> use this, since the SQRT function is generic, handling
    Vivek> both single and double precision arguments.

    Vivek> Maybe there should R coding standards to address such
    Vivek> issues. I hope that eventually the Fortran code in R
    Vivek> will use the modern features of Fortran 90 and later
    Vivek> standards, using the gfortran compiler. However, with
    Vivek> a little effort one can still write clean code in
    Vivek> Fortran 77 that also conforms to later standards.

I mostly agree with all you say above.

But we (R-core) have never wanted to play style-police for the
1000++ CRAN / bioconductor / omegahat R packages that other
people provide.

As core team we only feel responsible for the code that we
distribute with the R distribution, and even there, the so-called
recommended ("non-core") packages typically have their own
individual maintainer.
I'd say, R-core would typically follow your recommendations
above,  apart from the fact that most of us would not use
Fortran for developing new code.
And for legacy code that is well tested with many years of
history, we'd rarely want to spend the time just for beautifying
code (though I occasionally have done so, when wanting to find
      out what the code was doing at all).

Martin Maechler, ETH Zurich