Naming Conventions, which one?

This is probably one of the most personal guideline.

I have to admit that I have not yet found yhe one that I love so I often change my mind resulting into somehow disorder style (that really hurts my soul).

I read about many nice idea. I will try to report them here (I need some times, but do not wait me, start suggestiong your convention) in order to promote our discussion.
#### From Richard Maine (stated [here](https://groups.google.com/forum/#!topic/comp.lang.fortran/RQkKgktyj9g%5B76-100%5D))

> - Use _verb_ forms for subroutine names and _noun_ forms for functions, e.g. a function to return some useful thing might be named `useful_thing` while a subroutine would be better named something like `get_useful_thing`.
#### From one of the @cmacmackin [guides](https://github.com/Fortran-FOSS-Programmers/FIAT/wiki/Style-Guidelines#naming-conventions)

> - Names should be descriptive, especially for publicly visible entities. Underscores should be used to separate words if a name is more than two words long. If a name is only two words long then an underscore may be used at your discretion. Sometimes they make the name more readable, sometimes they just make it longer. As with anything else in the code, use lower cases characters only.
> - For identifiers avoid to exploit _Case_ to indicate different words within them when Fortran is case-insensitive, the language doesn't recognize it.
> - submodule could be useful for type/module names disambiguation (and for avoid recompilation cascade penalties when _implementation_ changes, but not the _interface_), but add **verbosity**: should be not recommended for small project.
#### From @certik [best practices](http://www.fortran90.org/src/best-practices.html)

> - Use lowercase for all Fortran constructs (`do, subroutine, module`, ...).
> - as consequence from lowercase adoption, exploit underscores rather than `camelCase`.
> - but the except is to follow short mathematical notation for mathematical variables/functions (`Ylm, Gamma, gamma, Enl, Rnl`, ...).
> - For other names use all lowercase: try to keep names to one or two syllables; if more are required, use underscores to clarify (`sortpair, whitechar, meshexp, numstrings, linspace, meshgrid, argsort, spline, spline_interp, spline_interpolate, stoperr, stop_error, meshexp_der`).
> - `camelCase` for variables comes from Java and I pretty strongly do not recommend it.
#### From @milancurcic best practices

> - reserved Fortran words in all uppercase - this is what I have mostly been doing in the past, however I recommend all lowercase for reserved words just as well.
> - variables lower-case
> - underscores for multi-word variables
> - camelCase for procedure names

``` fortran
TYPE :: datetime

INTEGER :: year = 1 ! Year [1-HUGE(year)]
INTEGER :: month = 1 ! Month in year [1-12]
INTEGER :: day = 1 ! Day in month [1-31]
INTEGER :: hour = 0 ! Hour in day [0-23]
INTEGER :: minute = 0 ! Minute in hour [0-59]
INTEGER :: second = 0 ! Second in minute [0-59]
INTEGER :: millisecond = 0 ! Milliseconds in second [0-999]

REAL(KIND=real_dp) :: tz = 0 ! Timezone offset from UTC [hours]

CONTAINS

PROCEDURE :: addMilliseconds
PROCEDURE :: addSeconds
PROCEDURE :: addMinutes
PROCEDURE :: addHours
PROCEDURE :: addDays
PROCEDURE :: isocalendar
PROCEDURE :: isoformat
PROCEDURE :: isValid
PROCEDURE :: now
PROCEDURE :: secondsSinceEpoch
PROCEDURE :: strftime
PROCEDURE :: tm
PROCEDURE :: tzOffset
PROCEDURE :: utc
PROCEDURE :: weekday
PROCEDURE :: weekdayLong
PROCEDURE :: weekdayShort
PROCEDURE :: yearday

ENDTYPE datetime
```
#### From @rouson best practices

> - prefer all lowercase
> - prefer _underscores_ over camelCase => `add_milliseconds` over `addMilliseconds`
> - use mixed case in situations where underscores are not allowed, e.g., in defined operators and in `name=` field of _bind(C)_ pricedures when applicable:
>
> ``` fortran
> type foo
> contains
> procedure :: negate_foo
> generic :: operator(.negateFoo.) => negate_foo
> end type
> ```
> - procedure names must have an action verb in them.
> - logical variables must be named to reflect the state they are used to convey, most with the verb _to be_, e.g. :
> - `lib_is_initialized` vs `lib_init`;
> - `obj_has_parent` vs `obj_parent`;
> - do not strive to much in _local shortening_ of variables name, prefer meaningful name: local shortening is often possible with the `associate` construct.
> - avoid single character suffix for types and modules, e.g. `_t` and `_m`, because:
> - a single character has the lowest information entropy possible in a language. Probably for this reason, conveying meaning with a single character is bound to confuse anyone who is not already familiar with the convention.
> - I have no problem with borrowing from other languages, but there just aren’t enough Fortran programmers doing this for it to be widely a widely recognizable convention.
> - on the contrary prefer suffix like `_interface` to module names and `_implementation` to submodule names.
#### From @victorsndvg best practices

> - exploit _camelCase_ over underscores;
> - prefer a complete meaningful _action-descriptive_ name for procedures, even if the resulting name is very very long, e.g. `PerformAnActionWithThisVariableOfTypeXXXWhileThisContext`
> - prefix type bound procedures (TBP) with the type name for allowing an easy _refactoring_ of codes (it becomes very easy to move _class_ from a module into a new one without change the procedures names), e.g.
>
> ``` fortran
> type :: my_object
> contains
> procedure :: action => my_object_PerformAnActionWithThisVariableOfTypeXXXWhileThisContext
> end type
> ```
#### From @zbeekman best practices

> - exploit `camelCase` for procedures to be able to immediately identify an entity as a procedure.
> - names must have meaning.
> - procedure names must have an action verb in them.
> - named constants (parameters?) are in `UPPERCASE`.
> - logical variables must be named to reflect the state they are used to convey, most with the verb _to be_, e.g. :
> - `lib_is_initialized` vs `lib_init`;
> - `obj_has_parent` vs `obj_parent`;
> - append `_t` to derived type names and `_m` to module names to help _namespace_: you can have modules with effectively the same name as the class they implement, and one could even declare an object with the same name as the derived type/class if one wanted to do so; also the `_t` is a common convention in some other languages like C.
#### From @LadaF best practices

> - prefer undescores over `camelCase` due to consistency with the Fortran standard naming convention and the case insensitivity of names Fortran.
> - structure constructors and other similar function should **not** have any verb in them, their name is just what they return, due to consistency with the Fortran standard default and overloaded structure constructors naming.
> - avoid module suffixes, expect (maybe) for type names _disambiguation_, e.g.
>
> ``` fortran
> type(Sphere) :: sphere ! won't work
> type(spere_t) :: sphere ! works
> ```
#### From @tclune best practices

> - prefer undescores over `camelCase` due to consistency with the Fortran standard naming convention and the case insensitivity of names Fortran.
> - however, `camelCase` could be admissible for module names and type names; in fact, type names are _proper nouns_ in the language, and as such, I at least one to capitalize them; moreover, `camelCase` helps to accentuate this when the noun is multiple words; but more importantly it often solves type names _disambiguation_, e.g.
>
> ``` fortran
> type (SphereShape) :: sphere_shape ! or just sphere
> ```
> - append `_t` to derived type names to disambiguation aims could be help, it could be considered superfluous, i.e. my usual pattern is to define one “class” per Fortran module prefix `pkg_` (over suffix with `_mod`) for all modules in the package, e.g.
>
> ``` fortran
> module pkg_SphereShape_mod
> ...
> type :: SphereShape
> ```