Talk - Reka/Ben: Actionable insights vs ranking How to use and how NOT to use code quality metrics

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