|
1 | 1 | # Fortran stdlib Style Guide
|
2 | 2 |
|
3 |
| -This document will describe the code style to use. |
| 3 | +Adopting a consistent style can improve code legibility through the choice of good naming conventions. |
| 4 | +In addition, style checks will be run during CI to flag any severe non-conformance. |
| 5 | +This allows code review discussions to focus on semantics and substance rather than pedantry. |
| 6 | +Consistent whitespace usage, and not polluting line endings with trailing white space makes `git diff`s considerably more legible. |
| 7 | +This style guide is a living document and proposed changes may be adopted after discussing them and coming to a consensus. |
| 8 | + |
| 9 | +## Use (modern) standard Fortran |
| 10 | + |
| 11 | +* Do not use obsolescent or deleted language features |
| 12 | + E.g., `common`, `pause`, `entry`, arithmetic `if` and computed `goto` |
| 13 | +* Do not use vendor extensions in the form of non-standard syntax and vendor supplied intrinsic procedures |
| 14 | + E.g., `real*8` or `etime()` |
| 15 | + |
| 16 | +## File naming conventions |
| 17 | + |
| 18 | +* Source files should contain at most one `program`, `module`, or `submodule` |
| 19 | +* The filename should match the program or module name and have the file extension `.f90` or `.F90` if preprocessing is required |
| 20 | +* If the interface and implementation is split using submodules the implementation submodule file should have the same name as the |
| 21 | + interface (parent) module but end in `_implementation` |
| 22 | + E.g., `string_class.f90` and `string_class_implementation.f90` |
| 23 | +* Tests should be added in the `tests` subdirectory and have the same name as the module they are testing with the `test_` prefix |
| 24 | + added |
| 25 | + E.g., `string_class.f90` and `tests/test_string_class.f90` |
| 26 | + |
| 27 | +## Indentation & whitespace |
| 28 | + |
| 29 | +By setting and following a convention for indentation and whitespace, code reviews and git-diffs can |
| 30 | +focus on the semantics of the proposed changes rather than style and formatting. |
| 31 | + |
| 32 | +* The body of every Fortran construct should be indented by __two (2) spaces__ |
| 33 | +* Line length *should be limited to 80 characters* and __must not exceed 132__ |
| 34 | +* Please do not use <kbd>Tab</kbd> characters for indentation |
| 35 | +* Please remove trailing white space before committing code |
| 36 | + |
| 37 | +## Variable and procedure naming |
| 38 | + |
| 39 | +* Variable and procedure names, as well as Fortran keywords, should be written in lowercase |
| 40 | +* Variable and procedure names should be made up of one or more full words separated by an underscore, |
| 41 | + for example `has_failed` is preferred over `hasfailed` |
| 42 | +* Where conventional and appropriate shortening of a word is used then the underscore may be omitted, |
| 43 | + for example `linspace` is preferred over `lin_space` |
| 44 | + |
| 45 | +## End <scope> block closing statements |
| 46 | + |
| 47 | +Fortran allows certain block constructs or scopes to include the name of the program unit in the end statement. |
| 48 | +The convention adopted herein is to include procedure names, `module` names and `program` names in the `end` statement, |
| 49 | +unless the closing statement can reasonably be expected to be on the same screen or page, within about 25 lines. |
0 commit comments