Description
In this talk, we want to make two major points:
- Metrics can facilitate better conversation about code quality. They help you focus more on technical problems and improvements instead of personal preferences and organizational issues.
- Metrics can be misused very easily. Knowing their limitations is crucial.
METRICS
For each metric, we'll discuss:
- code examples in Python
- how to calculate
- interpretation (incl. some comparison across open source Python projects)
- actions
- limitations
METHOD LENGTH
The simple.
You can calculate it without specific tools. First step: Extract functions. It shows well some general limitations of code quality metrics.
CYCLOMATIC COMPLEXITY
The old.
Show the formula, but don't explain it in detail. :-) Extract functions. Remove redundant if conditions. It doesn't account for nested coding constructs. It ignores some modern language patterns.
COGNITIVE COMPLEXITY
The human.
Calculation and interpretation: see https://www.sonarsource.com/docs/CognitiveComplexity.pdf Actions: Extract functions. Use shorthand structures. More Pythonic code is also more readable. Limitations: It ignores both the length of a linear block and the complexity of the expressions used in it.
WORKING MEMORY
Another aspect of human understanding.
Calculation: see https://sourcery.ai/blog/working-memory/ Interpretation: The 7 +/- 2 rule of the human working memory. Actions: Extract functions, some more specific refactorings this metric rewards. Limitations: It ignores the structure.
LIMITATIONS AND PITFALLS
GENERAL
- They can be gamed.
- They easily encourage one-sided thinking and behaviour.
SPECIFIC FOR CODE QUALITY METRICS
- Great as warning signs, not good as "proof of excellence".
COMPOUND METRICS
- Giving a more versatile picture than a single metric.
WHAT METRICS DON'T CAPTURE
- naming, consistent terminology, ubiquitous language (DDD)
- project structure
- correctness