u: :to-url view layout[p: field"ftp://user:pass@yourwebsite.com/"[either dir? u v: value[f/data: read u v show f][editor u v]]f: text-list[editor u join p/text value]]

1 line :)

At the same time LOC is never used for estimation in a standalone way. It is via Baselining Techniques or COCOMO model.

For LOC, SEI has specified which will be considered to be part of counting and which can not be. And again, your organization may have some different way of calculation also.

You can have a look at:

http://art-of-project-management.blogspot.com/2008/03/estimation-technique-lines-of-code.html

However, havin said all these, bottom line is what kind of engineers you have, what kind of expertise you have and above all the committment to work. Nothing can beat that.

And may be that is reason why so many IT project (read project management) which are not in good shape even with proliferation of so many tools/techniques.

In this project we are automatically parsing the schema of a large legacy database into a custom XML format, and then using XSLT to generate model and controller classes and Velocity macros for views to create a classic MVC application (in C# and Monorail, but actually that makes little difference). So very few of those lines of code are actually hand-written.

And that provides an interesting sidelight into the lines of code debate in more than one way. What are the ‘source lines of code’? The roughly 3,500 lines of sed script and XSL transforms which I actually wrote, the roughly 66,000 lines of the (automatically derived) database schema, or the 700,000 plus lines of C#, Velocity, NHibernate and other stuff which they generate?

If I hadn’t written the auto-generators, that code would still have to have been written (we might have been motivated to write it more tightly, but it would still have been in hundreds of thousands of SLOC). So the number of lines of code you actually write is not a good measure of project size, and the number of lines of code produced is not, either.

And remember, this is happening all down the software stack. I use XSL-T to generate Java, C# or some other high level language. The compiler takes that high level language and in an analogous process generates what in BCPL we used to call ‘CINT Code’ – machine instructions for a virtual machine. The run time system takes the CINT code and generates machine instructions. And inside the processor, the microcode interpreter takes those machine instructions and uses them to generate actual machine operations.

At each stage in the process, the number of discrete statements increases. Which should you count? Why? Even at the level of a binary, a larger binary does not necessarily deliver more functionality than a smaller one.

The other thing is, where a mechanical process is generating code, fixing one bug in the generator will fix hundreds or even thousands of bugs in the generated code. So my hunch is that while functionality scales more-or-less with the number of generated lines of code, bugs scale more or less with the number of lines of code in the generator.

There’s a misunderstanding of the way people who advocate LOC as a metric actually use it. Until that misunderstanding is corrected, this discussion will remain at an impasse.

@RG — Can you contact me via email? I posted my contact info with my comment.

Out of curiosity, would you consider the libraries that come with a GPL/BSD J2EE stack to be in the quality bracket with .NET, or with a random GPL library? What about the libraries that come with the Apache httpd server? And are you really using C# and .NET as examples of robust code, where the bug forums are subject to public inspection?

In either case, if you are evaluating code that I wrote for a project, why on earth would you care how many LOC are in the libraries I use? They are not part of the code you are evaluating, much like the OS, app server stack, etc. Like you said, we need to know context. If I am writing an application for Windows, we know the context is that the OS will slow everything down and make it crash sometimes for no fault of mine. In other words, we know the libraries I use all the way down to the OS level are buggy. But you don’t count that against me. Why not think the same way about OSS libraries? Some are buggy, some aren’t. But here’s another point for you to evaluate: choice of libraries. Did I make a good choice or not?

Also, you may want to familiarize yourself with logical SLOC: http://en.wikipedia.org/wiki/Source_lines_of_code. I think this concept will make you feel a lot better about LOC as a measurement. Note that you can measure logical LOC without obfuscating code. Specifying a method at 50 logical SLOC does tell us something useful about the code vs a method with the same goals that is 500 SLOC written by the same person.

Your arguments against LOC are similar to the arguments against using weight as a partial measure of health. No, one number will not tell you everything you need to know about the situation. But that doesn’t mean you stop measuring it, or ignore the numbers you have. Doctors are professionals who have to measure complex systems, and they work with the metrics that they can gather. Why is this method not appropriate for software developers?

And again, what are you proposing instead?

RG- There’s an implied quality difference between packaged standard libraries for a language (C# depends on the .NET framework, for instance) and a third party library that you lifted off a website because it was GPL and did everything you wanted to do yourself. “Well-Tested in the field” helps keep the bug count in check, but I’ve yet to see a popular library under active development with a bug forum/list that’s been empty for any real period of time.

I don’t have anything against running code through a formatter- It’s the context vacuum that bothers me. 5 lines could mean two lines of “meat” and three lines of organization (brackets, whitespace, comments, whathaveyou). Personally I have nothing against counting whitespace and documentation- If you work somewhere that’s judging you based on LOC, you should still get points for making your code more readable. It’s just that reporting a number like “50 lines of code” without specifying how it’s counted doesn’t tell us anything about the code quality or complexity. Numbers without context are how that famous quote originated- “There are three kinds of lies. Lies, Damned lies, and statistics.”

“a skilled Java programmer could write a Web content management application in fewer lines of code than a skilled assembly programer, in their respective languages” – Definitely. It would, indeed, be ridiculous to dispute that. Also it definitely remains true throughought the higher level languages: Ruby backends will have fewer LOC than C backends, etc. But that’s just another way that LOC can mean less in a vacuum of context. Saying “I wrote this in 600 lines of code” tells us pretty much nothing of the code quality, bug count, or programmer’s skill without knowing at LEAST what language they used, how much of the code was already done for them (again, not counting libraries bundled with the language distribution- those simply establish a benchmark) by third party libraries/frameworks, and maybe actually looking at the code to see whether it was written in an intelligent manner or a clever(e.g Perl Golf) one.

For example, Unless you know for a fact that Average
programmer in the US, age between 25-30 makes n% of defects
per million line of codes, this kind of defects measurement is
absurd. You can only define the level of defects only if you
know for certain what is the measuring stick.

Fewer LOC is a good objective that every manager should drive
their team to achieve. Having less code to manage is always a
good thing. But it is superficial to equate LOC to quality.

Increase in LOC is always a result of the increase in the
number of coressponding process, or functions or modules that
the programmer have to write. Sometimes things like defensive programming and reflective programming that wasnt in the official use case scenarios adds more LOC into the software but the software gains tremendous quality gains.

LOC metrics makes sense only if it is analyzed with the number
of process the programmer had to translate into codes.
Better algorithm does not equal less codes.
Does the manager factor in that fact when considering overall
quality of the software?.

Trying to put an “ideal” quantity to a dependant variable Y
(quality / defect) when it is a product of independant
variables Y=ax + bx + Nn which you cant quantify only gives
false sense of quality. How would one know how many LOC is ideal just by looking at the number of SLOC?

One line of text does not equal one line of code or program statement. It is not a measure of “thinking unit” of a programmer. Judging the competency of your programmers using LOC is ill informed and misguided.