SonarQube is a software product which runs various coding style rules and other metrics similar to FxCop or Re-sharper. It defines breaking the style rules as:
This is commonly referred to as technical debt. Issues associated with maintainability are named “code smells” in our products."
However, I would normally think of technical debt as "A piece of code which doesn't follow the overall architectural pattern."
For example, say we have a business rules layer, but as a quick fix we put one bit of business logic in the UI layer.
Or, say we have a project which is very OOP, but we add a procedural helper class for a new feature.
The code might well meet all the style rules, have no duplication etc and be fine on its own. Its only considered technical debt because it doesn't fit the pattern of the other code in the project. In order to make the project 'nice' again we need to go back and refactor it so that everything works the same way.
I would think that this kind of difference would be hard to pick up with code analysis rule sets and it seems disingenuous to call style rule violations "technical debt".
Am I wrong or right? Do some objective rules or some class of rules make a good definition of technical debt or at least a type of technical debt?
this tool will tell management that a line of code
Is 2min worth of tech debt. Which seems wrong.
However, it will also do the same thing for cyclomatic complexity or duplicate code. Which seems less wrong.