Skip to main content
Computer Science Educators

Return to Answer

move my other answer to here
Source Link
ctrl-alt-delor
ctrl-alt-delor
  • 10.8k
  • 4
  • 25
  • 54

In any case, I could not count lines of code. Even looking for outliers is throughthrought with dangers.

A few years back, when I remember the quality manager coming to me withwas a big grin on his facesoftware engineer. He had just gotSome one introduced a new codesoftware metrics analysertool. He had run the code for a large medical pump projectIt measured Mccabe complexity (that I was working onvarious complexities of the code), through it. It showed that one of my modules hadwas a very, verygood tool, and very high value for couplinguseful. Much, much higher than any other moduleYou could find parts of the code that were un-usual. I asked to seeOften you could find bugs by examining these parts of the data, it showed near zero for every other metriccode. I smiled and looked across

One day the head of QA came to me, screaming. He was waving a bit of paper with the nameresults of the tests. It showed that a module, itthat I had written had a complexity for class dependency that was ……… something_factoryoff the chart. YesI pointed out that all the other complexity metrics were close to zero. He screamed, "but what about this one". I pointed out, that this class was a factory, it was this modulesits job to own this complexity, because it would be worse to have allit spread about. I said "if it was spread about, then the couplingmetrics would not find it, so other module could have none..." he interrupted "then spread it about". I continued "... but then the code would be much more complex." -- He looked back at me blackly.

We stopped using the quality manager, withtool shortly after that. A shame. It was a smilegood tool. But heIt helped us find bugs. However it did not understand why I was smilingtell us where the bugs were. It took several meetings with my boss and human resourcestold us what the probably bug density is, if you knew how to finally get him offread it.

So yes lines of our backscode can be useful, but only as a statistical tool.

In any case, I could not count lines of code. Even looking for outliers is through with dangers. I remember the quality manager coming to me with a big grin on his face. He had just got a new code metrics analyser. He had run the code for a large medical pump project (that I was working on), through it. It showed that one of my modules had a very, very, very high value for coupling. Much, much higher than any other module. I asked to see the data, it showed near zero for every other metric. I smiled and looked across to the name of the module, it was ……… something_factory. Yes, it was this modules job to have all the coupling, so other module could have none. I looked back at the quality manager, with a smile. But he did not understand why I was smiling. It took several meetings with my boss and human resources, to finally get him off of our backs.

In any case, I could not count lines of code. Even looking for outliers is throught with dangers.

A few years back, when I was a software engineer. Some one introduced a software metrics tool. It measured Mccabe complexity (various complexities of the code). It was a good tool, and very useful. You could find parts of the code that were un-usual. Often you could find bugs by examining these parts of the code.

One day the head of QA came to me, screaming. He was waving a bit of paper with the results of the tests. It showed that a module, that I had written had a complexity for class dependency that was off the chart. I pointed out that all the other complexity metrics were close to zero. He screamed, "but what about this one". I pointed out, that this class was a factory, it was its job to own this complexity, because it would be worse to have it spread about. I said "if it was spread about, then the metrics would not find it, ..." he interrupted "then spread it about". I continued "... but then the code would be much more complex." -- He looked at me blackly.

We stopped using the tool shortly after that. A shame. It was a good tool. It helped us find bugs. However it did not tell us where the bugs were. It told us what the probably bug density is, if you knew how to read it.

So yes lines of code can be useful, but only as a statistical tool.

Source Link
ctrl-alt-delor
ctrl-alt-delor
  • 10.8k
  • 4
  • 25
  • 54

Reason 1 : Because without printing it out you can not weigh it.

When I was an university, there was a myth that some lazy teachers (I don't know the technical terms for the roles), would weigh your reports, and give a grade base on that. I heard of one student that handed in some work with a load of blank paper attached, and got a good grade.

Reason 2 : To see how complex it is.

I remember a story by Michael Jackson, about judging how brilliant some one is. I will include the last 3 paragraphs here.

“Terrific,” I mumbled respectfully. I got the picture clearly. Fred as Frankenstein, Fred the brilliant creator of the uncontrollable monster flowchart. “But what about Jane?” I said. “I thought Jane was very good. She picked up the program design ideas very fast.”

“Yes,” said the DP Manager. “Jane came to us with a great reputation. We thought she was going to be as brilliant as Fred. But she hasn't really proved herself yet. We've given her a few problems that we thought were going to be really tough, but when she finished it turned out they weren't really difficult at all. Most of them turned out pretty simple. She hasn't really proved herself yet — if you see what I mean?”

I saw what he meant.

Reason 3 : To see how complex it is.

Over complex code is bad, see in working out the final grade, the number of lines of code, goes some ware in the denominator.

Reason 4 : Looking for outliers

This is the only one that would make any sense, but people do a lot of thinks that don't make sense.

Because they knew how many line it should take, and they were looking for statistical outliers. If the line count is way off then it is a sign of a problem.

Summary

In any case, I could not count lines of code. Even looking for outliers is through with dangers. I remember the quality manager coming to me with a big grin on his face. He had just got a new code metrics analyser. He had run the code for a large medical pump project (that I was working on), through it. It showed that one of my modules had a very, very, very high value for coupling. Much, much higher than any other module. I asked to see the data, it showed near zero for every other metric. I smiled and looked across to the name of the module, it was ……… something_factory. Yes, it was this modules job to have all the coupling, so other module could have none. I looked back at the quality manager, with a smile. But he did not understand why I was smiling. It took several meetings with my boss and human resources, to finally get him off of our backs.