It does take all KINDS, as they say. Perhaps because I did a lot of hand calculations where you tended to use a single-character symbol to represent a lot of operations and variables I often find multi-line formulas expressed in long descriptive names more obscure than clear, and am often happier with a comment containing keys defining the meaning of the letters more pleasing. That being said, it can be useful to have long descriptive names at times where the code almost reads as prose, and that is particularly nice for long stretches of code with short expressions. So how I like to name things depends on the context. But in general, one of the reasons I like modules is that I can create procedures with long descriptive names, but rename them easily with a USE statement when I want something shorter. So I like the proposed gen_long_name syntax for procedures in modules, and think that the USE statement is the best place to create the short name.
But just because it was a unique request, I thought I would mention what someone asked me to do – give everything a long and short name. They did not want to use “USE, ONLY :” which is what I prefer. They wanted to just load the entire module with a simple “USE, NAME”. So I do not recommend this, but tastes differ: You can give a procedure multiple names in the same module with an interface. The real case was more complicated as the vast majority of the procedures were generic and so on but the basic idea is simple to show with a trivial example:
module M_math
implicit none
private
public :: generate_sin_of_radians, sinr
public :: generate_sin_of_degrees, sind
real,parameter :: R2D=1.0/57.2957795131 ! degrees
interface sind
module procedure generate_sin_of_degrees
end interface sind
interface sinr
module procedure generate_sin_of_radians
end interface sinr
contains
elemental function generate_sin_of_radians(radians)
real,intent(in) :: radians
real :: generate_sin_of_radians
generate_sin_of_radians=sin(radians)
end function generate_sin_of_radians
elemental function generate_sin_of_degrees(degrees)
real,intent(in) :: degrees
real :: generate_sin_of_degrees
generate_sin_of_degrees=sin(degrees*R2D)
end function generate_sin_of_degrees
end module M_math
program test
use M_math
real,parameter :: PI=atan(1.0)*4.0
write(*, *)generate_sin_of_radians( [ 0.0, PI/4.0, PI/2.0, PI ] )
write(*, *)sinr( [ 0.0, PI/4.0, PI/2.0, PI ] )
write(*, *)generate_sin_of_degrees( [ 0.0, 45.0, 90.0, 180.0 ] )
write(*, *)sind( [ 0.0, 45.0, 90.0, 180.0] )
end program test
So, although I don’t really like it myself you can use an interface with just one module procedure in it to give the same routine an alias when you define it in a module. In this case they wanted exactly that – a long and short name for all the procedures. I hadn’t really thought of doing that until asked.
Since then, I have found that useful when I want to casually rename a procedure but provide backward compatibility with the old name in my own non-production code. I just go ahead and rename it if I change my mind, and then make a one-line interface so the old name still works and mark the old name as deprecated.
There are other ways to do similar things; but I found it interesting the first time it came up, and it does provide an alternative – instead of deciding between long and short names, provide both in one module without writing a wrapper procedure! Sort of an obvious subcase of generic procedures once you think of it, but like I said – it had not occurred to me until someone asked for that feature.