Fortran Best Practices -- comments #313
Description
I think the suggested best practices are sound and thank the authors for writing this. Here are my comments.
"canonical" not "cononical" at https://fortran-lang.org/learn/best_practices
Add comma before "and" to get "Here is a style guide that we like and that seems to be prevalent in most scientific codes (as well as the Fortran standard library), and you are welcome to follow it." at https://fortran-lang.org/learn/best_practices/style_guide
For naming conventions, I suggest that short, especially one-letter variable names for integers and reals follow Fortran's implicit typing rules, although one should use implicit none. A variable i should be an integer and x should be a real, for example.
A naming convention I would suggest is to use consistent names for integer variables in a do loop. For example, to loop over days of data,
do iday=1,ndays
...
end do
Also, it is common for an integer variable starting with n to denote a loop bound or array dimension and for a variable starting with i to be a loop variable. So one would not write
do nday=1,idays
...
end do
At https://fortran-lang.org/learn/best_practices/floating_point I would write
a = real(1, dp) / 2 ! 'a' is equal to 0.5_dp
more concisely as
a = 1.0_dp / 2 ! 'a' is equal to 0.5_dp
"distinguishes" not "distinguishs" at https://fortran-lang.org/learn/best_practices/integer_division
"name clashes" not "nameclashes" at https://fortran-lang.org/learn/best_practices/modules_programs
At https://fortran-lang.org/learn/best_practices/modules_programs use, only is done for imports, which I agree with, but it should be explained that this reduces name clashes and helps the reader understand where imported entities are coming from.
At https://fortran-lang.org/learn/best_practices/arrays include a colon in "To pass arrays to procedures four ways are available:" and a hyphen in "higher-dimensional".
I think "with" should be "which" in "Note that the shape is not checked, therefore the following would be valid code with will potentially yield incorrect results:" at https://fortran-lang.org/learn/best_practices/arrays .
Replace "Finally, there are assumed-size arrays, which provide the least compile and runtime checking and can be found be found frequently in legacy code, they should be avoided in favour of assumed-shape or assumed-rank arrays." with "Finally, there are assumed-size arrays, which provide the least compile-time and run-time checking and can be found be found frequently in legacy code. They should be avoided in favour of assumed-shape or assumed-rank arrays."
Replace the first comma in "Note that size returns the total size of all dimensions, to obtain the shape of a specific dimension add it as second argument to the function." with "--" to avoid a run-on sentence.
"annotated" not "annoted" at https://fortran-lang.org/learn/best_practices/arrays .
The code examples use argument intent, but is there a place where that is explicitly suggested and justified?
For "Allocatable arrays can be passed to optional dummy arguments, if they are unallocated the argument will not be present." replace the comma with -- or break into two sentences to avoid a run-on at https://fortran-lang.org/learn/best_practices/allocatable_arrays . Same comment for the comma after "array" in "Finally, allocations do not initialize the array, the content of the uninitialized array is most likely just the bytes of whatever was previously at the respective address."
For "Alternatively, status="replace" can be used to overwrite an existing file, it is highly recommended to first check for the existence of a file before deciding on the status to use. " a new sentence should start with "it" to avoid a run-on at https://fortran-lang.org/learn/best_practices/file_io .
Replace "are" with "is" in "A useful IO feature are scratch files."
Replace "integratable_function" with "integrable_function" at https://fortran-lang.org/learn/best_practices/callbacks .
Replace "Exporting the abstract interface allows to create procedure pointers with the correct signature and also to extend the callback further like shown here" with "Exporting the abstract interface allows you to create procedure pointers with the correct signature and also to extend the callback further as shown here"
Why use Roman numerals instead of the usual Arabic digits in https://fortran-lang.org/learn/best_practices/type_casting ?