>I'm not sure I can agree with the "totally meaningless" label we're assigning to LOC counts. As the project lead on a very large OOP/Procedural hybrid application, I'm coming up with more and more uses for the LOC count. I'll identify two (both of which are identified in Pigoski's Practical Software Maintenance c.1996 ISBN: 0-471-17001-1)
>
>1. Determining Complexity: We are beginning an effort to identify selections of code as being too complex. In order to do this, we count and weight all branches in the code (IF/CASE/FOR/Etc.)[McCabe's Cyclomatic Complexity]. Steve McConnell does a good job of summarizing this process in Code Complete. In order to track this complexity, it is practically mandatory that we know how many lines of code there are in the particual procedure. A procedure with a complexity rating of 8 doesn't sound bad, unless it's only 15 lines long. The converse is also true. A complexity level of 20 is really high, but what if the routine is 1000 lines long because of some text/string wrangling? A goal of our effort is to reduce the overall level of complexity in this project. That is why we require the overall LOC count. We need some number to use for our complexity quotient (i.e. COMPLEXITY / LOC)
>
>2. Tracking Annual Change Traffic (ACT): The owners of the system need to have an idea of what paying paying their maintenance team for. Research shows that 80% of all "maintenance" is Enhancement, not Bug Fix. How else would you report the metrics of the year's work without reporting ACT? I suppose you could report on function points added, removed, changed, but how would you track that? If you track DELETED lines, ADDED lines and CHANGED lines as the numerator and LOC as the denominator, the ACT quotient you get is meaningful. I.e., in 1997 we had an ACT of 18%, 1998 12%. Etc. SourceSafe allows you to, relatively easily, track this. We are developing a SourceSafe automation based ACT counter.
>
>Now, I agree that these two examples are on the esoteric fringe. And, these examples refer purely to software maintenance. So, if your job is strictly to develop and then walk away, perhaps you can get by without any attention to metrics. But, as a developer who is getting called in to organize more and more VFP Maintenance efforts, I'd sure like it if more developers didn't.
>
Marty,

I don't believe your examples are necessarily on the "esoteric fringe". They are actually an instance of the general problem of how to guage complexity and difficulty of development/maintenance of application software.

All of us have to consider such complexity and difficulty questions, if only to give prospective client an idea of how much it will cost and how long it will take. For those in the business as independent providers, accurately guaging complexity (thus time and effort) may mean the difference between profit and misery.

The issue is whether, in an OOP environment, line counts are a good measure of difficulty and complexity. Several of the members here suggest they are not, you suggest they may be, giving well reasoned and cogent argument.

I respectfully agree -- and disagree.

When you count lines of code in VFP, what are you counting? Do you count the lines of code that would have been written if all of the objects had be created, instantiated etc. through code? This is a false count since rarely does one add such elements to a project through code. Drag-drop and subclassing are the usual means.

The only code written any more is user defined methods and event handlers -- and even these are ordinarily written once, then subclassed.

I have a huge form I am working on now -- 5 main pages, 17 minor pages, about 1100 objects all together. Yet I'll be I have not written more than 3,000 lines of code. But if you view the source code in the class browser, it will tell you that the form required about 72,000 lines of code -- that is, had I created the form completely through code, I would have written 72,000 lines of code. But in fact I did not (thank all major and minor deities wherever located!).

So which is the more accurate measure of complexity -- the 72,000 lines I did not write, or the 3,000 that I did write? If you accept the 3,000 lines as the measure, how do you account for the clever (grin) use of sub-classed objects that reduced the amount of code I needed to write?

Obviously, counting lines is can no longer be the sole measure of complexity as it was in the days of procedural code.

While I would not go so far as to say line counts are now meaningless, I would say that they are certainly not as meaningful as they once were.

Just my one penny's worth,

regards,