0

In the paper On the correlation between size and metric validity Gil and Lalouche conclude that all popular software metrics are only valid insofar as they are correlated with code size.

They use several definitions of size including lines of code, number of tokens, and size of gzipped code.

Are there any actionable conclusions we can draw from this other than write less code if possible?

Do I understand correctly that "instability", "bugginess", and "change complexity" scale linearly with code size? Does that mean even splitting one big project into several smaller projects is doomed to have the same absolute number of bugs and no other objective metric is better than code size for this purpose?

Improve this question
3
  • Is there a way to review the paper in question for free?
    – tale852150
    Commented Jan 6, 2018 at 0:13
  • Google Sci-Hub @tale852150
    – Alex L
    Commented Jan 6, 2018 at 0:17
  • Thx. I tried Google and the first half dozen links wanted $$$... I’ll try your suggestion.
    – tale852150
    Commented Jan 6, 2018 at 0:19

1 Answer 1

Reset to default
1

After reading the paper I believe what the authors suggest is that the higher the correlation between the software engineering metric and the code/artifact/program size, the higher the validity the metric for determining "instability", "bugginess", and "change complexity".

Are there any actionable conclusions we can draw from this other than write less code if possible? No and I don't think even "write less code if possible" is a logical conclusion or actionable item based on this paper alone. Write "clean code" would be better than "less code".

Do I understand correctly that "instability", "bugginess", and "change complexity" scale linearly with code size? Based on this paper, 'yes'. But, all other things being equal, intuitively I would think to be so even without the author's research.

Does that mean even splitting one big project into several smaller projects is doomed to have the same absolute number of bugs and no other objective metric is better than code size for this purpose? No, I don't think the authors proved either of these statements -- absolute # of bugs and no other objective metric.

Remember that the authors are showing a correlation between code size and metric validity for predicting "instability", "bugginess", and "change complexity". There is a big gulf between correlation and causation.

Improve this answer
3
  • Thanks for your answer @tale852150! Although writing "clean code" is conventional wisdom I don't see how that could possibly be a conclusion of this paper. To the contrary, all measures of cleanliness that the authors compared did no better than the metric amount of code.
    – Alex L
    Commented Jan 6, 2018 at 20:32
  • @AlexL - you welcome. And you are correct - the paper does not promote “clean code”. That was just my personal opinion. That is, “clean code” is a matter of choice and preferred in my experience over just “concise” code. That is, write code that is clear (readable) as well as “concise” as opposed to just “concise”.
    – tale852150
    Commented Jan 6, 2018 at 20:39
  • @AlexL - if you think my response is acceptable please mark it as an answer. Thank you.
    – tale852150
    Commented Jan 7, 2018 at 12:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.