Best_Practices
Best_Practices copied to clipboard
the opinionated *best practices* of Fortran FOSS Programmers group
Hi, All. I don't know where to put this question so I write it here. It seems the GitHub does not understand the modern Fortran syntax. Not even the modern...
What would be the best way of specifying the kind parameter? Should we always use the `selected_*_kind` function, `integer, parameter :: dp = selected_real_kind(15, 307)` `real(dp) :: x` or are...
While I feel that there is no one-size-fits-all choice for an appropriate license for new Fortran software projects, and trying to reach a consensus and trying to make a specific...
From a note on another thread... > avoid dead code, do not write code that has no effect Is this an agreed guideline? The discussion is open :smile: # Summary...
First of all, Stefano and everyone suppporting here, I think you are doing a great job, I think this sort of effort has long been missing in the FORTRAN community....
I recently used the term "Fortran idioms" or possibly "idiomatic Fortran" on comp.lang.fortran and someone commented that they weren't sure such a thing exists, which makes me think that it...
I feel that there is an almost unanimous agreement on that `implicit none` must be mandatory, but I guess many of you will provide interesting _exceptions_, so > do you...
For readability/debugging/robustness/safeness (what else?) purposes it could be interesting to add a guideline about > use keyword argument calling-style for all optional arguments in procedures callings e.g. ``` fortran subroutine...
This is a continuation of #7. For discussion about choosing a license for a _project_ please see #8. Any off topic comments here will be deleted (and possibly moved to...
Just a list (with no special order) of sources for inspiring us > feel free to correct/expand it - [Fortran 2003 standard](http://www.j3-fortran.org/doc/year/04/04-007.pdf) - [Modern Fortran: Style and Usage](http://www.amazon.com/Modern-Fortran-Norman-S-Clerman/dp/052173052X) - [The...