When designing a bridge, an architect has al sorts of tools & techniques to verify it won't collapse. Us software developers... We build. And with a bit of luck, we'll even test. And then we pray it doesn’t collapse :) Can we measure software? Can we compare code objectively? Can we predict problems?

1. Measure twice, cut once
SOFTWARE METRICS

2. @matthiasmullie
Software metrics

3. Make software measurable
instead of relying on intuition.
Software metrics

4. Presentation titleSoftware metrics

5. Presentation titleSoftware metrics

6. Presentation titleSoftware metrics

7. Software metrics
COMPLEXITY

8. Every code path adds complexity
Counts # of code paths
Software metrics » Complexity
Cyclomatic complexity

9. • Analyze control flow
• Start at 1
• Increase at every decision path
(if, for, case, …)
Software metrics » Complexity
Cyclomatic complexity

10. if ($user->isLoggedIn()) {
echo 'Welcome back, ' . $user->getName();
} else {
echo 'Hi there, stranger!';
}
Cyclomatic complexity = 2
Software metrics » Complexity
Cyclomatic complexity

11. Every code path adds complexity
Counts # possible outcomes
Software metrics » Complexity
NPath complexity

12. Software metrics » Complexity
NPath complexity
if ($user->getSalutation()) {
echo $user->getSalutation().' ';
}
if ($user->getName()) {
echo $user->getName();
} else {
echo 'anon';
}
Outcomes: • $salutation anon
• anon
• $salutation $name
• $name

13. Every operation adds complexity
Software metrics » Complexity
Halstead measures

14. • Analyze vocabulary
• Count amount of operators
(+, -, =, &&, ... and reserved words,
like if and for)
• Count amount of operands
(values, variables & function names)
Software metrics » Complexity
Halstead measures

15. if ($user->isLoggedIn()) {
echo 'Welcome back, ' . $user->getName();
} else {
echo 'Hi there, stranger!';
}
Operands = 4 (4 unique)
Software metrics » Complexity
Halstead measures

16. if ($user->isLoggedIn()) {
echo 'Welcome back, ' . $user->getName();
} else {
echo 'Hi there, stranger!';
}
Operators = 11 (7 unique)
Software metrics » Complexity
Halstead measures

17. Engineered to match human analysis
Software metrics » Complexity
Maintainability index

18. Combination of:
• Cyclomatic complexity
• Halstead measures
• Lines of code
Software metrics » Complexity
Maintainability index

19. Metrics for matthiasmullie/minify, MatthiasMullieMinifyJS::stripWhitespace
See https://www.cauditor.org/matthiasmullie/minify/c17eb048daa44b43fa98bfa405147e77a040df76/metrics
Software metrics » Complexity
Maintainability index

20. Questions?
Software metrics » Complexity

21. Software metrics
COUPLING

22. Amount of incoming dependencies
= other classes using this one
Common for core functionality
Software metrics » Coupling
Afferent coupling

23. class Afferent
{
function __construct() {}
}
class Efferent
{
function __construct(Afferent $a) {}
}
Afferent: 1, Efferent: 0
Software metrics » Coupling
Afferent coupling

24. Changes here may break things elsewhere
Must be stable & thoroughly tested
Software metrics » Coupling
Afferent coupling

25. Amount of outgoing dependencies
= other classes being used
Common for controllers
Software metrics » Coupling
Efferent coupling

26. class Afferent
{
function __construct() {}
}
class Efferent
{
function __construct(Afferent $a) {}
}
Afferent: 0, Efferent: 1
Software metrics » Coupling
Efferent coupling

27. • Harder to read/maintain
• Harder to reuse
• Harder to test in isolation
• Brittle
Software metrics » Coupling
Efferent coupling

28. Changes elsewhere may break things here
Probably violates single responsibility
principle
Software metrics » Coupling
Efferent coupling

29. = efferent coupling / total coupling
= efferent coupling / (efferent + afferent)
Resilience to change
Software metrics » Coupling
Instability

30. High efferent coupling
= likely to be impacted by changes in
= other classes
= not stable
Software metrics » Coupling
Instability

31. Low afferent coupling
= change is easy because there isn’t much
= that depends on this
= not stable
Software metrics » Coupling
Instability

32. Stable = good
… as long as you don’t need to change
the implementation!
Software metrics » Coupling
Instability

33. Aim for extremes, make classes as stable
or unstable as possible!
Unstables can be refactored/decomposed
later. Better than having dependencies
everywhere.
Software metrics » Coupling
Instability

34. Counts # of ancestors
Software metrics » Coupling
Depth of inheritance

35. class Ancestor {}
DIT: 0
class Descendant1 extends Ancestor {}
DIT: 1
class Descendant2 extends Descendant1 {}
DIT: 2
Software metrics » Coupling
Depth of inheritance

36. Inheritance is not bad!
• Code reuse
• Polymorphism
Software metrics » Coupling
Depth of inheritance

37. But too much is!
• Less stable: change in ancestor can
affect descendants
• More complexity: methods of all
ancestors are inherited
Software metrics » Coupling
Depth of inheritance

38. Questions?
Software metrics » Coupling

39. WHY WOULD I CARE?
Software metrics

40. Presentation titleSoftware metrics » Usage
Which would you rather maintain?

41. Presentation titleSoftware metrics » Usage

42. Software metrics » Usage
Complexity
This guy has
something going on!
Let’s see…

43. It’s not too crazy! But:
• Recursion
• 3 loops
• 4 conditions
• Callback function
Software metrics » Usage
Complexity

44. Method does too much:
• Data transformation
• Processing
• Cleanup
Hard to test & prove right!
Software metrics » Usage
Complexity

45. Software metrics » Usage
Complexity
This guy
has a lot
going on…

46. Presentation titleSoftware metrics

47. Software metrics » Usage
Coupling
• Lots of outgoing
dependencies
• Some inheritance
Very brittle!

48. Changes in any of these
could affect this class!
Software metrics » Usage
Coupling

49. Software metrics » Usage
Refactoring
• 1000+ LOC class
• Pretty complex
• Very unstable
• Self-contained, barely
reusable

50. Software metrics » ObservationsSoftware metrics » Usage
Reduced
complexity
everywhere
Decreased +
increased
stability

51. Software metrics » Observations
Refactoring
• Greatly reduced
“monster class”
• Split into multiple
reusable pieces
Software metrics » Usage

52. Questions?
Software metrics » Usage

53. OBSERVATIONS
Software metrics

54. Software metrics » Observations
Spikes!

55. Complexity often caused by a few commits!
Watch out with new features & rewrites.
Software metrics » Observations
Spikes!

56. Presentation titleSoftware metrics » Observations

57. Software metrics » Observations
No evolution

58. • No change over time
• No change across projects
Do developers have a “signature”?
Software metrics » Observations
No evolution

59. Software metrics » Observations
Personalities?
2 guys working on same project:
• One was very fast (but messier)
• One was a lot more thorough
Who’s who?

60. Software metrics » Observations
Personalities?

61. Software metrics » Observations
Personalities?
M
essy
Thorough

62. Software metrics » Observations
Personalities?
Can metrics show personality traits?
Please help me figure that out!
https://www.cauditor.org/user/feedback

63. Presentation title

64. Questions?
Software metrics

65. mullie.eu
• mullie.eu/measuring-software-complexity
• mullie.eu/measuring-software-coupling
• cauditor.org/help/metrics
Software metrics
Resources