Define a consistent naming scheme for derived types

[fortran-lang]

Define a consistent naming scheme for derived types

[certik]

Is the reason to append _t as in user_t so that the variable can be named user, as in type(user_t) :: user?

It might be helpful to go over the most popular codes listed in https://github.com/fortran-lang/stdlib/wiki/List-of-popular-open-source-Fortran-projects and see what conventions they use and list them here, so that we can make a more informed decision.

[rweed]

Yes and also to allow the module that contains the class/type to be named with a similar name so that there is no conflict.

ie

Module userClass

Type :: UserClass_t

This is one of the things recommended in Clerman and Spector's very excellent book, "Modern Fortran, Style and Usage" although I saw it used by other folks prior to their book. Again just another way of avoiding naming conflicts. Note you can always rename it on USE if you prefer in your code. Just makes the name somewhat unique. Adding an _et for extended types just gives you a visual signal in the source that the type is extended from something else when the original code author might have chosen to make all or parts of the class private.

[septcolor]

FWIW, my convention is also similar to the above one (i.e., UserClass_t) such that it does not interfere with local variable names. I also sometimes rename it into a shorter one (e.g., FB_t => FooBaa_t) when importing it in a local module (if I want to type less). But I am also interested in other conventions.

[ivan-pi]

The appended _t for types and _m for modules is also found in the "opinionated" best Fortran practices: https://github.com/Fortran-FOSS-Programmers/Best_Practices

Sometimes I also go for the longer _type to be more explicit. The iso_fortran_env module contains a lock_type as example.

[milancurcic]

So far we've been using a _type suffix though not 100% consistently:

• stdlib_bitsets provides bitset_type, but also bitset_64 and bitset_large that extend bitset_type. The latter two should be renamed to bitset_64_type and bitset_large_type.
• stdlib_logger provides logger_type
• stdlib_string_type provides string_type

I opened #332 to solicit feedback about making the convention 100% consistent. But otherwise, we have a good enough convention so I will close this.