Many times it is hard to imagine different meaningful names for modules, main type declared in a module and an instance of the type. Examples in programming books generally use examples which do not have this problem. For example: circle, square, triangle can be instances of type(shape). However, I often find myself urge to have things like a declaring a variable with name vortex of type(vortex) defined in module named vortex. This is a common problem across languages, but Fortran has an added layer due to the requirement of defining types in a module. Many Fortran programmers add _m and _t to module and type names, perhaps, to overcome this. Personally, I do not like it. Also, I would like to reserve _t for things like time derivative and _m for max/min value.
Right now I deal this on a case by case basis. Sometimes, if possible, using plurals, as in module vortices. Any better solution would be welcome.
Edit: I’ve tried to soften the tone and be less offensive
As a quick-fix, if you are bothered by the _t you can rename on import, e.g.
use pathlib, path => path_t
type(path) :: pth
Unfortunately, this only applies to entities within a module.
To rename a module you can use a wrapper module:
module paths
use pathlib, only: &
path => path_t, & !< base class
home, canonical, cwd !< utility procedures
end module
Just make sure your wrapper module remains synchronized with the upstream version. It’s probably a good idea to use public/private as an extra precaution.
I used to be of the same opinion as you, but lately I have started using the _t suffix and have actually started to like it. The consistency is certainly a nice benefit.
I typically use the following convention: A source file named {name}.f90 with a module named {name}_mod with a type named {name}_t.
If I’m making a type for a library I like to name the module {libname}_{name}. That way I don’t have to use the _mod suffix.
Example:
path.f90 (in a library called pathlib):
module pathlib_path
implicit none
type :: path_t
end type
(...)
end module
Usage:
use pathlib_path, only: path_t
type(path_t) :: path ! Or any other variable name if that makes sense
It would be interesting to do a poll to figure out what’s the most popular conventions. A common naming convention for the whole community is perhaps too ambitious, but one could of course hope for something like that…
Interesting question: I follow almost all @plevold’s conventions (except {libname}_{name}). The problem has been discussed (at least partially) within stdlib. I have solicited some more general discussion for the benefit of Fortran-lang projects, but no conclusive decisions have been made.
Isn’t there a reason why such things tend be listed under “style guides” and “naming conventions”?
To each their own will be a good way to approach this where consensus is likely highly elusive.
On a moderated forum like this which is trying to be welcoming, referring to others’ style and usage with a strong adjective like in the second quoted sentence above appears to fall in the category of personal opinions and views that needn’t be shared here.
I’m not sure about appending _m, however I took a note at a recent lecture series «Fortran for Scientific Computing» on futurelearn.com, moderated by Geert Jan Bex (Vlaams Supercomputer Centrum). When going into detail about user defined types in particular (week 3, object oriented programming in Fortran), he recommended_t e.g., by the statement
It is good practice to append the _t suffix to make it very clear that this is the name of a type.
regardless of liking/implementing OOP, or not.* The appended _t may help any reader used to this custom to identify the code’s design and to navigate in the lines (e.g., search by this very string). In a couple of weeks, it equally may be you. So, when in Rome, do as the Romans do.
*) The series included discussions from which I retain some situations favour OOP, and others don’t require OOP.
I agree. I have tried to soften the tone of the post. My motto was to explore alternatives somebody might offer, rather than offending anyone. I would never like to offend someone over something as petty as styling source code.
Thanks for bringing this issue up @mfurquan. I think having a more recommended style for this would be very helpful. Unfortunately so far we have not been able to agree on one. So for now we simply leave it as personal choice.
