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 outside this module on which types inside this module directly depends.

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.

[barnabasdomozi]

last week we discussed with @zporky on the weekly meeting, that each directory should be considered as a module.

Is this still the case? In PR #747 a new approach was suggested to specify a flag (such as -m) to a file which lists directories as modules. Which method should we implement for this metric?

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

I have a few questions below about this definition to make sure the right calculation is implemented:

"outside this module"

Does the outside directory has to be specified as a module (e.g. listed in the file specified by -m flag) or not?

Let's say Module A uses types T1, T2 which are not part of any module. Would that increase efferent coupling for Module A by 2?

"is the number of types inside this module"

What is considered exactly a type in this case?
Let's say Module A has a function foo which is not part of any type (e.g. class) and this function uses type T defined outside of this module. Would that count?

How about functions?
Let's say Module A uses 3 different functions (such as foo, bar, test) defined outside of this module. Would that increase efferent coupling by 3 for Module A?

My initial idea was to check all usages in a module (directory) and if their definition is defined outside of this module we simply increase efferent coupling. This would be the fastest one to calculate, however I'm not sure if this would be the intended behavior.