Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Define a consistent naming scheme for derived types #26

Closed
rweed opened this issue Dec 20, 2019 · 5 comments
Closed

Define a consistent naming scheme for derived types #26

rweed opened this issue Dec 20, 2019 · 5 comments
Labels
meta Related to this repository

Comments

@rweed
Copy link

rweed commented Dec 20, 2019

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

@rweed rweed closed this as completed Dec 20, 2019
@rweed rweed reopened this Dec 20, 2019
@certik
Copy link
Member

certik commented Dec 20, 2019

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
Copy link
Author

rweed commented Dec 20, 2019

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
Copy link

septcolor commented Dec 21, 2019

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
Copy link
Member

ivan-pi commented Dec 21, 2019

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.

@jvdp1 jvdp1 added the meta Related to this repository label Jan 18, 2020
@milancurcic
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
meta Related to this repository
Projects
None yet
Development

No branches or pull requests

6 participants