Collective Wisdom from the Experts 149
correlate with code quality. Two of a number of metrics that measure coupling
are fan-in and fan-out. Consider fan-out for classes: it is defined as the number
of classes referenced either directly or indirectly from a class of interest. You
can think of this as a count of all the classes that must be compiled before your
class can be compiled. Fan-in, on the other hand, is a count of all classes that
depend upon the class of interest. Knowing fan-out and fan-in, we can calcu-
late an instability factor using I = fo / (fi + fo). As I approaches 0, the package
becomes more stable. As I approaches 1, the package becomes unstable. Pack-
ages that are stable are low-risk targets for recoding, whereas unstable packages
are more likely to be filled with dirty code bombs. The goal in refactoring is to
move I closer to 0.
When using metrics, one must remember that they are only rules of thumb.
Based purely on math, we can see that increasing fi without changing fo will
move I closer to 0. There is, however, a downside to a very large fan-in value:
these classes will be more difficult to alter without breaking dependents. Also,
without addressing fan-out, you’re not really reducing your risks, so some balance
must be applied.
One downside to software metrics is that the huge array of numbers that met-
rics tools produce can be intimidating to the uninitiated. That said, software
metrics can be a powerful tool in our fight for clean code. They can help us
to identify and eliminate dirty code bombs before they are a serious risk to a
performance-tuning exercise.