-
Notifications
You must be signed in to change notification settings - Fork 177
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
Module naming convention #9
Comments
This would be ultimately fixed by j3-fortran/fortran_proposals#86, then the top level module would be called Until then, I suggest to use underscore to emulate "nested modules", so as you suggested, I would use I don't like the |
Or submodule... but yes I agree. |
We follow a convention on our project where there is one module per file, and the module name matches the filename. This is close to Python, where the file is the module. This has worked very well for us. (We also do not use any |
Closing in favor of #279. |
Changed capitalized words to lowercase + some typos
Co-authored-by: Jeremie Vandenplas <[email protected]>
Tangential to #3. The choice of a module naming pattern is important because a module with a generic name can cause conflict in the client code. In the absence of namespaces, the standard library modules should have a specific enough prefix to prevent such conflicts.
One approach could be to use
stdlib
for the top-level module;stdlib_<group>
for specific modules, e.g.stdlib_collections
,stdlib_sorting
, etc. you get the idea.In the recent years, I tend to name modules with a
mod_
prefix, e.g.mod_functional
. I see in the wild thatmodule_
,m_
prefixes, or even_m
suffix are used. If I name the source file the same as the module, then I can easily see which source files contain modules and which don't. To me, this is useful if I haven't looked at the library in a long time, but now I can't think of any other benefit to this "convention". If this convention is used for stdlib, then we'd have:mod_stdlib
mod_stdlib_<group>
However, this seems unnecessarily verbose, and most library files are likely to be modules anyway (with the exception of tests which would be programs in their own directory, see #7). Thus, if we use the
stdlib_
prefix universally, I don't think we needmod_
or similar.The text was updated successfully, but these errors were encountered: