4 ms·
I think you make a valuable point. If somebody writes concise, clear code with little duplication, but still has a bug, their stats might look worse simply beca
by leto_ii 6y ago
I think you make a valuable point. If somebody writes concise, clear code with little duplication, but still has a bug, their stats might look worse simply because their code is shorter.
It's also not clear that bug rates should be the only/main thing to look at. Complexity measures can also help to indicate if the code is easy to read/extend. In my experience low cyclomatic complexity does correlate with more readable code.
- tsimionescu 6y ago> If somebody writes concise, clear code with little duplication, but still has a bug, their stats might look worse simply because their code is shorter. Fortunately, the science here me to indicate the opposite: the less code you have, the fewer defects per LoC you'll have. This is also indicated in the article, which mentions that both function size and function length were found to be correlated to higher defect density, meaning that both may in fact simply be estimators of overall code length - that overall code length correlates with defect density per LoC. > It's also not clear that bug rates should be the only/main thing to look at. Complexity measures can also help to indicate if the code is easy to read/extend. In my experience low cyclomatic complexity does correlate with more readable code. The article does actually cite some (necessarily small-scale) studies on this as well, which have also tended to find that larger functions are easier to read for debugging purposes, and that it was easier to add new functionality to the system with larger functions; but that it was easier to modify the existing functionality of the system with smaller functions. This is all in the section entitled 'Practical Effects'.
- leto_ii 6y ago> Fortunately, the science here me to indicate the opposite: the less code you have, the fewer defects per LoC you'll have I judged things conditional on the fact that a bug exists. If you apply the technique of counting bugs/loc blindly you may end up favouring longer, more tangled code. Think about it this way: if your goal is low bugs/loc then when a bug shows up you will be incentivized to fix it in a way that increases loc, instead maybe of simplifying thing. This will lead to fewer bugs and lower bug density.