-
Notifications
You must be signed in to change notification settings - Fork 174
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
Comments
Is the reason to append 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 Sometimes I also go for the longer |
So far we've been using a
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. |
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
The text was updated successfully, but these errors were encountered: