mirror of
https://github.com/github/codeql.git
synced 2025-12-17 09:13:20 +01:00
73 lines
2.4 KiB
XML
73 lines
2.4 KiB
XML
<!DOCTYPE qhelp PUBLIC
|
|
"-//Semmle//qhelp//EN"
|
|
"qhelp.dtd">
|
|
<qhelp>
|
|
<overview>
|
|
<p>
|
|
This metric measures the number of incoming dependencies for each
|
|
module, that is the number of other modules that depend on it.
|
|
</p>
|
|
|
|
<p>
|
|
Modules that are depended upon by many other modules typically require a lot of
|
|
effort to change, because changing them will force their dependents to change
|
|
as well. This is not necessarily a bad thing -- indeed, most systems will have
|
|
some such modules (one example might be an I/O module). However, modules with a high number
|
|
of incoming dependencies and a high number of outgoing dependencies are hard to maintain.
|
|
A module with both high afferent coupling <em>and</em> high efferent coupling can be problematic
|
|
because, on the one hand they are hard to change (high afferent coupling), yet on the other they
|
|
have many reasons to change (high efferent coupling). This contradiction yields code that is very
|
|
hard to maintain or test.
|
|
</p>
|
|
|
|
<p>
|
|
Conversely, some modules may only be depended on by very few other modules. Again,
|
|
this is not necessarily a problem -- we would expect, for example, that the
|
|
top-level modules of a system would meet this criterion. When lower-level
|
|
modules have very few incoming dependencies, however, it can be an indication
|
|
that a module is not pulling its weight. In extreme cases, modules may even
|
|
have an afferent coupling of <code>0</code>, indicating that they are dead
|
|
code.
|
|
</p>
|
|
|
|
</overview>
|
|
<recommendation>
|
|
|
|
<p>
|
|
It is unwise to refactor a module based purely on its high or low number of
|
|
incoming dependencies -- a module's afferent coupling value only makes sense
|
|
in the context of its role in the system as a whole. However, when combined
|
|
with other metrics such as efferent coupling, it is possible to make some
|
|
general recommendations:
|
|
</p>
|
|
|
|
<ul>
|
|
<li>
|
|
Modules with high numbers of incoming <em>and</em> outgoing dependencies
|
|
are prime candidates for refactoring (although this
|
|
will not always be easy). The general strategy is to split the module into
|
|
smaller modules that each have fewer responsibilities, and refactor the code
|
|
that previously used that module accordingly.
|
|
</li>
|
|
|
|
|
|
<li>
|
|
Modules that have an afferent coupling of <code>0</code> may be dead code --
|
|
in this situation, they can often be deleted.
|
|
</li>
|
|
</ul>
|
|
|
|
|
|
|
|
</recommendation>
|
|
<references>
|
|
|
|
|
|
<li>
|
|
M. Fowler. <em>Refactoring</em>. Addison-Wesley, 1999.
|
|
</li>
|
|
|
|
|
|
</references>
|
|
</qhelp>
|