Skip to content

Commit 173d8fe

Browse files
authored
Merge pull request #42 from zbeekman/style-enforcement
Style guide (see #3)
2 parents 389255d + ad52b9f commit 173d8fe

File tree

3 files changed

+133
-1
lines changed

3 files changed

+133
-1
lines changed

Diff for: .editorconfig

+55
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,55 @@
1+
# EditorConfig file. For more info, please see:
2+
# https://EditorConfig.org
3+
4+
# top-most EditorConfig file
5+
root = true
6+
7+
# All files should have a final newline and not have trailing whitespace
8+
# but we need to explicitly enumerate files we care about to prevent random junk
9+
# from being linted
10+
11+
[*.{f90,F90}]
12+
indent_style = space
13+
indent_size = 2
14+
trim_trailing_whitespace = true
15+
max_line_length = 132
16+
insert_final_newline = true
17+
18+
[{CMakeLists.txt, *.cmake}]
19+
indent_style = space
20+
indent_size = 2
21+
trim_trailing_whitespace = true
22+
max_line_length = 132
23+
insert_final_newline = true
24+
25+
[*.md]
26+
max_line_length = off
27+
trim_trailing_whitespace = false
28+
charset = utf-8
29+
insert_final_newline = true
30+
31+
# Tab indentation (no size specified)
32+
[Makefile]
33+
indent_style = tab
34+
indent_size = 4
35+
trim_trailing_whitespace = true
36+
max_line_length = 132
37+
insert_final_newline = true
38+
39+
[*.sh]
40+
indent_style = space
41+
indent_size = 2
42+
trim_trailing_whitespace = true
43+
max_line_length = 132
44+
insert_final_newline = true
45+
46+
[*.nml]
47+
trim_trailing_whitespace = true
48+
max_line_length = 132
49+
insert_final_newline = true
50+
51+
[*.{yml,json}]
52+
indent_style = space
53+
indent_size = 2
54+
trim_trailing_whitespace = true
55+
insert_final_newline = true

Diff for: .gitattributes

+31
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,31 @@
1+
# Set the default behavior, in case people don't have core.autocrlf set.
2+
* text=auto
3+
4+
# Explicitly declare text files you want to always be normalized and converted
5+
# to native line endings on checkout.
6+
*.c text
7+
*.h text
8+
*.f90 text
9+
*.F90 text
10+
*.md text
11+
*.txt text
12+
*.sh text
13+
*.cu text
14+
15+
# Denote all files that are truly binary and should not be modified.
16+
*.mod binary
17+
*.o binary
18+
*.a binary
19+
*.so binary
20+
*.tar binary
21+
*.gz binary
22+
*.tgz binary
23+
24+
# Prevent dev-ops files from making it into the release archives
25+
.gitattributes export-ignore
26+
.gitignore export-ignore
27+
codecov.yml export-ignore
28+
.github export-ignore
29+
30+
# Perform substitutions when `git export`ing these files
31+
.VERSION export-subst

Diff for: STYLE_GUIDE.md

+47-1
Original file line numberDiff line numberDiff line change
@@ -1,3 +1,49 @@
11
# Fortran stdlib Style Guide
22

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

Comments
 (0)