  Background. The popularity of tools for analyzing Technical Debt, and
particularly the popularity of SonarQube, is increasing rapidly. SonarQube
proposes a set of coding rules, which represent something wrong in the code
that will soon be reflected in a fault or will increase maintenance effort.
However, our local companies were not confident in the usefulness of the rules
proposed by SonarQube and contracted us to investigate the fault-proneness of
these rules. Objective. In this work we aim at understanding which SonarQube
rules are actually fault-prone and to understand which machine learning models
can be adopted to accurately identify fault-prone rules. Method. We designed
and conducted an empirical study on 21 well-known mature open-source projects.
We applied the SZZ algorithm to label the fault-inducing commits. We analyzed
the fault-proneness by comparing the classification power of seven machine
learning models. Result. Among the 202 rules defined for Java by SonarQube,
only 25 can be considered to have relatively low fault-proneness. Moreover,
violations considered as "bugs" by SonarQube were generally not fault-prone
and, consequently, the fault-prediction power of the model proposed by
SonarQube is extremely low. Conclusion. The rules applied by SonarQube for
calculating technical debt should be thoroughly investigated and their
harmfulness needs to be further confirmed. Therefore, companies should
carefully consider which rules they really need to apply, especially if their
goal is to reduce fault-proneness.
