Skip to content

Module naming convention #9

Closed
Closed
@milancurcic

Description

@milancurcic

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 that module_, 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 need mod_ or similar.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions