Using mixedCase

[certik]

@everythingfunctional wrote in #56 (comment) and I am moving it to a separate issue here:

As a side note, what's the community consensus on mixed case? I've been working for the past few years under the assumption that it was ok to use mixed case as an aid to the reader, even if the compiler didn't care.

[certik]

The Fortran community has historically been agnostic if you use mixed case or upper case or lower case, so from this perspective, you can use whatever you prefer.

However, instead of each of us using incompatible naming conventions, I would like if we can come together as a community, and agree on a more unified style that we all follow. And then provide tooling (compilers) that can enforce it. Similar to Python's PEP8.

I like the Python's approach: https://www.python.org/dev/peps/pep-0008/#function-and-variable-names:

mixedCase is allowed only in contexts where that's already the prevailing style (e.g. threading.py), to retain backwards compatibility.

and I suggest we follow the same.

See also the discussion at:

fortran-lang/stdlib#3

which lead to:

https://github.com/fortran-lang/stdlib/blob/5d1e09131cad56467549ecd9d6b977cec19b2f35/STYLE_GUIDE.md

Also https://www.fortran90.org/src/best-practices.html#naming-convention. One can browse current open source Fortran codes here: https://github.com/fortran-lang/stdlib/wiki/List-of-popular-open-source-Fortran-projects. Some codes use mixedCase, but most codes seem to use lower_case_with_underscores.

[Leonard-Reuter]

This is a related to #118

I also like Pythons approach, and my Fortran programming is atm close to pythons PEP8:

• variables in lower_case_with_underscores
• types in CapWords convention
• parameters in SCREAMCASE

Additionally, I follow two advises from the book 'Modern Fortran: Style and Usage':

• routines in Upper_case_with_underscores. This is helpful to distinguish arrays from functions (which is not needed in python, because array access is with [ ]). In Fortran, for a = electrons(3), electrons could be both, an array and a function (although one with a stupid name).
• If the type has only one word (i.e. Circle), I add an _t (i.e. Circle_t) this way, I can still use circle for an instance of Circle_t. Again in python due to case sensitivity, this is not needed. This way, I can also distinguish a type constructor from one-word functions.

[certik]

I think what we need here is an automatic formatter that can enforce these things. For things where there are multiple opinions, we can allow it to be configurable, so that each project can set it up the way they like, similar to clang-format.

I like all your suggestions, except the subroutines where I personally prefer all lowercase (but I understand your argument about arrays). But this can be configurable in the formatter.

[HaoZeke]

For what its worth, I prefer camelCase myself. The snake_case variables to me seem longer somehow. Enforcing project level specifications feel out of scope for the J3 committee. Anything like PEP8 would be something for the standards committee but I would definitely strongly be against (completely ruins backward compatibility for one thing).