|
|
|
|
|
|
by mcherm
3815 days ago
|
|
|
You are pointing out that "lines of code" is a terribly imprecise metric. That is TRUE, but not HELPFUL. We all know that "lines of code" is a terrible metric. And for only $100/hr, for a few hours you can hire an expert to evaluate one file from your codebase and determine its size in something more reliable -- "function points" or some other system that you devise. The thing about "lines of code" is that it's CHEAP and EASY. It is also WAY better than having nothing. Which system is more complex, system A written in C++ 2003 or system B which was written Java in 2013? Which system is more complex, System C which is 200,000 lines or system D which is 10,000 lines? Even if I don't tell you how "lines" were defined in those two estimates, you can still tell more about C and D than about A and B. "Lines of code" is a terrible metric, which can give only order of magnitude estimates. But that makes it enormously better than no metric at all, or a complex metric which we haven't actually measured. |
|
|
A shorter function is a great side effect but it should never be the point. I want someone who can do things like: find obsolete code, create a better algorithm, decides on a better language for the task. If I say that a system is bad because it's 200,000 lines, I may discover that developers are really good at removing comments and obfuscating code to "improve" it down to 150,000 lines. If I come up with specific performance improvements, and state clear expectations such as "find functions we never use", I end up with a more maintainable system.