3 ms·

Maybe it's something as banal as there being a high enough chance of mistakes per LOC that this factor ends up dominating the other factors.

lallysingh 7y ago
There's also just reading/remembering costs per LOC that make it harder to track specifics about APIs and your own code. Smaller code fits in your head better, and stays more predictable. You don't have as many weird if-conditions to remember.
- iainmerrick 7y ago
  You don't have as many weird if-conditions to remember. More LOC doesn’t necessarily mean more if-conditions, though! For code written in different styles. It’s a strong statement that LOC and LOC alone is the best known predictor of bug rate, but that seems to be what several people in this thread are saying. For example, I think most people (though not all) would agree that very dense code full of tricky one-liners (think Perl Golf) is more likely to be buggy and hard to maintain. But if so, “number of control structures used” or some such ought to be a better metric than plain LOC (I assume we’re using “LOC” literally here, not as a shorthand for something else). Maybe there’s some second-order effect going on? Like very dense code discouraging modifications, so it gets less maintenance, and therefore accrues fewer bugs over time? This is an interesting topic! Any research links appreciated.
the_af 7y ago
Maybe. The key takeaway of this for me is: if you want to introduce a bug-predicting metric, you must do better than simple LOC count. If you can't do better, then ditch your metric :)
- MontyCarloHall 7y ago
  >if you want to introduce a bug-predicting metric, you must do better than simple LOC count Agreed. As I pointed out in another post[0], a good candidate for this metric is the amount of unnecessary code, which is often a proxy for unnecessarily large/complex teams. [0] https://news.ycombinator.com/item?id=21824110 https://news.ycombinator.com/item?id=21824110

lallysingh 7y ago

There's also just reading/remembering costs per LOC that make it harder to track specifics about APIs and your own code. Smaller code fits in your head better, and stays more predictable. You don't have as many weird if-conditions to remember.

iainmerrick 7y ago
You don't have as many weird if-conditions to remember. More LOC doesn’t necessarily mean more if-conditions, though! For code written in different styles. It’s a strong statement that LOC and LOC alone is the best known predictor of bug rate, but that seems to be what several people in this thread are saying. For example, I think most people (though not all) would agree that very dense code full of tricky one-liners (think Perl Golf) is more likely to be buggy and hard to maintain. But if so, “number of control structures used” or some such ought to be a better metric than plain LOC (I assume we’re using “LOC” literally here, not as a shorthand for something else). Maybe there’s some second-order effect going on? Like very dense code discouraging modifications, so it gets less maintenance, and therefore accrues fewer bugs over time? This is an interesting topic! Any research links appreciated.

the_af 7y ago

Maybe. The key takeaway of this for me is: if you want to introduce a bug-predicting metric, you must do better than simple LOC count. If you can't do better, then ditch your metric :)

MontyCarloHall 7y ago
>if you want to introduce a bug-predicting metric, you must do better than simple LOC count Agreed. As I pointed out in another post[0], a good candidate for this metric is the amount of unnecessary code, which is often a proxy for unnecessarily large/complex teams. [0] https://news.ycombinator.com/item?id=21824110 https://news.ycombinator.com/item?id=21824110