Efferent Coupling at Module Level for C++

[mcserep]

Coupling is metric which can be computed for structural units at different levels (e.g. classes, namespaces, modules).
It measures how many other entities an entity depends on; and how many dependants it has.

The Efferent Coupling for a particular module is the number of types inside this module that depends on types outside this module.

High efferent coupling indicates that the concerned module is dependant.

[intjftw]

What do we consider a module in this case? An entire directory? So, for example, in CodeCompass, the plugins, parser and model directories are 3 different modules?

Another option is to consider the C++20 feature module but I guess it's not that widespread.

[mcserep]

What do we consider a module in this case? An entire directory? So, for example, in CodeCompass, the plugins, parser and model directories are 3 different modules?

Another option is to consider the C++20 feature module but I guess it's not that widespread.

A module is an abstract concept here. In case of CodeCompass parser is a module, but plugins is not a module, instead plugins/cpp is a module, as that is a cohesive logical unit of the program. But plugins/cpp/parser could also be considered a submodule in my view.

I see the following options:

1. A module is a C++20 module. Since we would like this feature to work pre C++20 codebases, we should not do this.
2. A module is defined by the user in some format. This would require significant work on specifying and implementing how it is defined, thus I suggest not to go on this way.
3. A module is a directory. Any directory, so in this case plugins, plugins/cpp, plugincs/cpp/parser and plugincs/cpp/parser/src could all be interpreted as modules. In this case we evaluate the module level metric for all directories, but it won't make sense for all directories. It will depend on the user to query the metric for the directories, where it is useful. I see this as a possible option.
4. A module is a namespace and we expect that the namespace hierarchy of the project analyzed is properly maintained. This is an alternative solution.

I will further discuss this question with @zporky today.

[mcserep]

@intjftw Update: last week we discussed with @zporky on the weekly meeting, that each directory should be considered as a module. Later maybe it would be wise to require some input (a whitelist) about which directories are interesting, so we do not calculate these metrics for directories, where it does not make sense, but for now, we roll with this approach.