Define a consistent naming scheme for derived types
Closed this issue · 5 comments
I think we should have as part of the style guide and/or coding practices a standard naming convention (or two) for derive types. I currently append an _t tail to all derived type names ala
Type :: user_t
However, as I use more extended types and classes I'm considering either using _et or _c to define
an extended type. ala
Type :: user_et or user_c
Just an idea I would like to throw out
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.
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.
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.
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.
So far we've been using a _type suffix though not 100% consistently:
stdlib_bitsetsprovidesbitset_type, but alsobitset_64andbitset_largethat extendbitset_type. The latter two should be renamed tobitset_64_typeandbitset_large_type.stdlib_loggerprovideslogger_typestdlib_string_typeprovidesstring_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.