# Defining formatting styles for Fortran
**URL:** https://fortran-lang.discourse.group/t/defining-formatting-styles-for-fortran/4201
**Category:** Uncategorized
**Created:** [August 23, 2022, 9:34am UTC](https://fortran-lang.discourse.group/t/defining-formatting-styles-for-fortran/4201 "2022-08-23T09:34:39Z")
**Posts on this page:** 20
**Page:** 1
### Author:  [@gnikit](https://fortran-lang.discourse.group/u/gnikit)
#### Post date: [August 23, 2022, 9:34am UTC](https://fortran-lang.discourse.group/t/defining-formatting-styles-for-fortran/4201/1 "2022-08-23T09:34:39Z")
As far as I know Fortran does not have any defined code formatting styles (not to be confused with `FORMAT` specifiers for I/O). All present formatting tools impose whatever formatting style the authors deem important, which is not optimal.
Do you think it would be worth defining certain styles, similar to clang’s `GNU`, `LLVM`, `Mozilla`, etc. that would predefine things like:
- line width
- line spacing
- operator spacing
- variable definitions + keywords e.g. `integer, dimension(:) :: val` vs `integer :: val(:)`
If yes, what would you like to see included in a formatting style?
I don’t think that the formatting styles should necessarily cover 100% of the Fortran syntax (at least at first) given that would be a major piece of work to produce.
---
### Author:  [@Carltoffel](https://fortran-lang.discourse.group/u/Carltoffel)
#### Post date: [August 23, 2022, 11:18am UTC](https://fortran-lang.discourse.group/t/defining-formatting-styles-for-fortran/4201/2 "2022-08-23T11:18:02Z")
I really like the idea.
Recently, I tried to follow the style guide @everythingfunctional posted two years ago ([Free Style Guide](https://fortran-lang.discourse.group/t/free-style-guide/280)).
Additionally, I try to add comments in a way FORD understands them.
Maybe it would be possible to collect all the things we need to cover (spacing, naming, etc.) first. And in the next step we could “vote” on default values for them, like indentation width etc.
Tools could then take these values and users of these tools shouldn’t need to change much, as the default values represent the average user.
---
### Author:  [@everythingfunctional](https://fortran-lang.discourse.group/u/everythingfunctional)
#### Post date: [August 23, 2022, 12:36pm UTC](https://fortran-lang.discourse.group/t/defining-formatting-styles-for-fortran/4201/3 "2022-08-23T12:36:14Z")
I think it’s a worthwhile endeavor. I’d be more in favor of something like PEP8, but for Fortran. It’s also worth exploring what aspects of formatting Fortran code are there, as suggested by @Carltoffel.
---
### Author:  [@plevold](https://fortran-lang.discourse.group/u/plevold)
#### Post date: [August 23, 2022, 1:03pm UTC](https://fortran-lang.discourse.group/t/defining-formatting-styles-for-fortran/4201/4 "2022-08-23T13:03:20Z")
Naming conventions for types and (maybe) modules would be good. Like a `_t` suffix for types and a `_m` or `_mod` suffix for modules.
Ideally a module name suffix shouldn’t be needed. I don’t think module names ever will clash with procedure or type names, but it seems like it’s still needed. Gfortran and ifort both reject this example, but I don’t see why it shouldn’t be allowed:
```fortran
module foo
implicit none
private
public foo
contains
subroutine foo()
write(*,*) 'foo'
end subroutine
end module
program main
use foo, only: foo
call foo()
end program
```
---
### Author:  [@awvwgk](https://fortran-lang.discourse.group/u/awvwgk)
#### Post date: [August 23, 2022, 1:04pm UTC](https://fortran-lang.discourse.group/t/defining-formatting-styles-for-fortran/4201/5 "2022-08-23T13:04:50Z")
I would be more than happy to have a `black` like formatter for Fortran and consistently apply it for all my projects, would remove one big headache when developing. My only concern for formatters is that they should be complete for all whitespace and diff friendly. Many clang format styles use hanging indents, which can case big diffs in case of name changes.
---
### Author:  [@snano](https://fortran-lang.discourse.group/u/snano)
#### Post date: [August 23, 2022, 3:17pm UTC](https://fortran-lang.discourse.group/t/defining-formatting-styles-for-fortran/4201/6 "2022-08-23T15:17:15Z")
That would be great; something similar to the python PEP style formatting will help a lot in terms of code fast readability in the entire Fortran community.
---
### Author:  [@RonShepard](https://fortran-lang.discourse.group/u/RonShepard)
#### Post date: [August 23, 2022, 4:15pm UTC](https://fortran-lang.discourse.group/t/defining-formatting-styles-for-fortran/4201/7 "2022-08-23T16:15:04Z")
A common problem that occurs in projects with several authors is that they all have their own preferences for trivial things like how much to indent do loops or how to align dummy argument lists. When one author applies his changes to a code and commits it to the repository, then all of those changes show up in the diff listings, swamping any of the actual changes that were made.
In fortran, this especially occurs with legacy fixed-format code. One of the first things I like to do with such code, even if it was originally written by me, is to convert to free format and indent do loops, if blocks, etc. Then someone else wants to compare my new version to the previous version, and he needs to look manually at every line of the code instead of just that single line where I fixed a sign mistake. This is more than just ignoring white space in the diff listings, it includes the change in continuation lines, declaring intent() for dummy arguments, replacing labeled `continue` with `enddo`, and so on.
One solution to this problem is to use an automatic formatting tool that is invoked whenever code is committed to the repository. Then any diffs that are displayed would eliminate many of the trivial changes to the text.
---
### Author:  [@gnikit](https://fortran-lang.discourse.group/u/gnikit)
#### Post date: [August 23, 2022, 4:38pm UTC](https://fortran-lang.discourse.group/t/defining-formatting-styles-for-fortran/4201/8 "2022-08-23T16:38:39Z")
I agree. My original thinking was that we first need to create a style guide(s) (PEP8-like) and then enforce the style(s) with any of the following formatting tools:
- a standalone formatter similar to `black`.
- using LSP requests for [`textDocument/formatting`](https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#textDocument_formatting).
- using a compiler to run lint/format check. `lfortran` is currently capable of formatting, files and I expect its formatting capabilities will drastically improve in the near future.
@RonShepard the easiest way I can think automating this process would be with git hooks and pre-commit. That should be relatively easy to do and in theory we could create hooks now with the existing formatting tools that we have (`findent` and `fprettify`).
* * *
I would be more interested in having a discussion oh how that style guide should look like. What coding practices we should aim to promote and discourage. The idea being that we should pick styling features that are widely accepted and increase readability, rather than the personal taste of a single individual, which is how existing formatting tools are written.
---
### Author:  [@14ngp](https://fortran-lang.discourse.group/u/14ngp)
#### Post date: [August 23, 2022, 5:13pm UTC](https://fortran-lang.discourse.group/t/defining-formatting-styles-for-fortran/4201/10 "2022-08-23T17:13:49Z")
For modules, I usually prepend the name of the package, I got to like this pattern at stdlib, as it feels more natural.
```fortran
! src/something/foo.f90
module something_foo
private
public foo
contains
subroutine foo()
write(*,*) 'foo'
end subroutine
end module
```
> [@kargl](#):
>
> Are 6 error messages produced by gfortran insufficient?
Parsing is hard, ambiguity, I know: but the point stills valid.
The fact that we have ambiguity in “- (binary)” and “- (unary)” didn’t stop someone to pursue that feature.
I wonder if a name in module name statements would appear in any other context other than in use statements. A more honest answer should be is harder to implement as we don’t have much help in compilers, right?
---
### Author:  [@plevold](https://fortran-lang.discourse.group/u/plevold)
#### Post date: [August 23, 2022, 5:22pm UTC](https://fortran-lang.discourse.group/t/defining-formatting-styles-for-fortran/4201/11 "2022-08-23T17:22:16Z")
C++ allows namespaces and functions to have the same name. I don’t see why the Fortran standard couldn’t allow for the same.
If you go to any discourse with the intent of starting silly arguments you’ll always find something, but you won’t be contributing anything of value.
---
### Author:  [@14ngp](https://fortran-lang.discourse.group/u/14ngp)
#### Post date: [August 23, 2022, 8:18pm UTC](https://fortran-lang.discourse.group/t/defining-formatting-styles-for-fortran/4201/14 "2022-08-23T20:18:25Z")
I guess OP understand why the code _currently_ doesn’t work (Ex: I know the “law” is X) but is asking himself why it can’t work (Ex: what is the reasoning behind what the legislators did?).
But let’s not derail this thread, please, is about introducing a proposal for code style that is agreed upon in the community.
---
### Author:  [@egio](https://fortran-lang.discourse.group/u/egio)
#### Post date: [August 23, 2022, 8:21pm UTC](https://fortran-lang.discourse.group/t/defining-formatting-styles-for-fortran/4201/15 "2022-08-23T20:21:20Z")
I like to put spaces around % in order to improve readability. Like in:
```auto
type(point_t) :: point
... point % x ...
```
Sorry I’m writing from a mobile.
---
### Author:  [@14ngp](https://fortran-lang.discourse.group/u/14ngp)
#### Post date: [August 23, 2022, 8:50pm UTC](https://fortran-lang.discourse.group/t/defining-formatting-styles-for-fortran/4201/16 "2022-08-23T20:50:01Z")
I spend a lot of time aligning at least the function body because I believe it’s easier to read, there may be a problem with the line size (which I don’t encounter often), so I use my judgement to decide.
```fortran
subroutine write(self, unit, iotype, v_list, iostat, iomsg)
!! Represents a [[Hamiltonian]] showing each [[MatrixElement]]
!! block on screen
!! Example: `write(*,'(DT)') H`
class(Hamiltonian), intent(in) :: self
integer, intent(in) :: unit
character(*), intent(in) :: iotype
integer, intent(in) :: v_list(:)
integer, intent(out) :: iostat
character(*), intent(inout) :: iomsg
end subroutine
```
---
### Author:  [@ivanpribec](https://fortran-lang.discourse.group/u/ivanpribec)
#### Post date: [August 24, 2022, 5:38am UTC](https://fortran-lang.discourse.group/t/defining-formatting-styles-for-fortran/4201/17 "2022-08-24T05:38:00Z")
Personally, I don’t like aligning, exactly because of the extra work it introduces. Also if some of the dummy variables have additional attributes besides intent, such as `pointer`, `target`, `save`, or `contiguous` you have to make a decision how to deal with the extra whitespace. But as the old saying goes, [_de gustibus non disputandum est_](https://en.wikipedia.org/wiki/De_gustibus_non_est_disputandum).
Concerning free-form styles, source code from NAG follows a very distinct style, where Fortran keywords are capitalized. You can see this in their LAPACK examples: [LAPACK\_Examples/dbdsdc\_example.f90 at master · numericalalgorithmsgroup/LAPACK\_Examples · GitHub](https://github.com/numericalalgorithmsgroup/LAPACK_Examples/blob/master/examples/source/dbdsdc_example.f90). Other properties of this style include 2-space indentation for nested constructs, and a 4-space empty zone used for format and goto labels. I presume the style can be achieved using the [NAG source file polishing tool](https://www.nag.com/nagware/np/r71_doc/nagfor.html#POLISH). (Note: personally I’m not a fan of this style, as I can’t be bothered to capitalize Fortran keywords.)
---
### Author:  [@han190](https://fortran-lang.discourse.group/u/han190)
#### Post date: [August 24, 2022, 6:21am UTC](https://fortran-lang.discourse.group/t/defining-formatting-styles-for-fortran/4201/18 "2022-08-24T06:21:04Z")
If such a formatting style is created, please also include at least one type of preprocessors (for example, fypp). Personally, I don’t have any preference as long as the style used in one project is consistent.
---
### Author:  [@cmaapic](https://fortran-lang.discourse.group/u/cmaapic)
#### Post date: [August 24, 2022, 10:02am UTC](https://fortran-lang.discourse.group/t/defining-formatting-styles-for-fortran/4201/19 "2022-08-24T10:02:02Z")
Jane and I use the following in getting a consistent syle
nagfor =polish ch0401.f90 -alter\_comments -noblank\_cmt\_to\_blank\_line -blank\_line\_after\_decls -break\_long\_comment\_word -format\_start=100 -format\_step=10 -idcase=L -indent=2 -indent\_continuation=2 -indent\_max=16 -keep\_blank\_lines -keep\_comments -kwcase=L -leave\_formats\_in\_place -margin=0 -noindent\_comment\_marker -noseparate\_format\_numbering -relational=F90+ -renumber -renumber\_start=100 -renumber\_step=10 -separate\_format\_numbering -terminate\_do\_with\_enddo -width=132
we don’t capitalise Fortran keywords.
---
### Author:  [@Beliavsky](https://fortran-lang.discourse.group/u/Beliavsky)
#### Post date: [August 24, 2022, 12:47pm UTC](https://fortran-lang.discourse.group/t/defining-formatting-styles-for-fortran/4201/20 "2022-08-24T12:47:25Z")
> [@egio](#):
>
> I like to put spaces around % in order to improve readability. Like in:
>
> ```auto
> type(point_t) :: point
>
> ... point % x ...
>
> ```
>
> Sorry I’m writing from a mobile.
I would not do that because it looks like `point` and `x` are two separate variables and that `%` is operating on them. Tastes vary.
---
### Author:  [@Beliavsky](https://fortran-lang.discourse.group/u/Beliavsky)
#### Post date: [August 24, 2022, 1:09pm UTC](https://fortran-lang.discourse.group/t/defining-formatting-styles-for-fortran/4201/21 "2022-08-24T13:09:35Z")
Some other formatting decisions are
1. Spacing in `intent(in out`), `end do`, `end if` etc.
2. The ordering of attributes in an argument declaration. All the declarations in
```auto
subroutine foo(x,y,z)
real, intent(out), allocatable, optional :: x(:)
real, allocatable, intent(out), optional :: y(:)
real, optional, intent(out), allocatable :: z(:)
end subroutine foo
```
are valid. Argument intent should appear in all new code, so that attribute will be present for all arguments and should appear first, but I don’t have a strong view of whether `allocatable` should appear before `optional`.
---
### Author:  [@Jcollins](https://fortran-lang.discourse.group/u/Jcollins)
#### Post date: [August 24, 2022, 1:34pm UTC](https://fortran-lang.discourse.group/t/defining-formatting-styles-for-fortran/4201/22 "2022-08-24T13:34:27Z")
Different people and establishments have different preferred styles. I think it is much more valuable to be able to convert code safely between different styles See the thread:
> [@Fprettify, Patrick Seewald seeks collaborator](https://fortran-lang.discourse.group/t/fprettify-patrick-seewald-seeks-colaborator/4199/7):
>
> Well, that was a failure wink I forgot that the forum translates text to html so all of the text like \ silently disappeared. Second attempt, perhaps more meaningful - fpt code formatting commands LAYOUT: keep layout - As input file set layout - As below fixed format tab format - the VMS style with a tab as the leading character free format LINE LENGTH: output code line length \ page width \ - controls comment…
---
### Author:  [@14ngp](https://fortran-lang.discourse.group/u/14ngp)
#### Post date: [August 24, 2022, 3:04pm UTC](https://fortran-lang.discourse.group/t/defining-formatting-styles-for-fortran/4201/23 "2022-08-24T15:04:56Z")
> [@Jcollins](#):
>
> Different people and establishments have different preferred styles.
That is why black, blue and other python formatters exists other than [PEP8](https://pep8.org/), but it would be nice to have a simple code style guide to begin with, that doesn’t rely on a tool.
> [@ivanpribec](#):
>
> extra work it introduces
True! One of the reasons I think this kind of formatting shouldn’t be in Fortran’s “PEP8”, as it is more suited for an automated tooling rather than a person typing manually (I still do it anyway, is not rational xD).
> [@Beliavsky](#):
>
> two separate variables and that `%` is operating on them
As there is no `%` operator, only non-fortran people (and I had this experience yesterday) would look at that and think this way, and a code style should at least presume that a person reading the code knows the language. But full disclaimer, I do both.
> [@Beliavsky](#):
>
> I don’t have a strong view of whether `allocatable` should appear before `optional`.
I like putting `optional` at last, `intent` at first, and the others in the middle, as I deem in a user perspective more important to know which argument is optional.
* * *
Gathering enough information about such variations, we could create a pool to see if a pattern emerges on “which decision would you make in order to format the following given code”, but maybe I’m overthinking it.
[Next page](https://fortran-lang.discourse.group/t/defining-formatting-styles-for-fortran/4201.md?page=2)