Some people claim that code's worst enemy is its size, and I tend to agree. Yet every day you keep hearing things like
Question: When is "#lines of code" useful?
ps: Note that when such statements are made, the tone is "more is better".
I'd say it's when you're removing code to make the project run better.
Saying you removed "X number of lines" is impressive. And far more helpful than you added lines of code.
I'm surprised nobody has mentioned Dijkstra's famous quote yet, so here goes:
My point today is that, if we wish to count lines of code, we should not regard them as "lines produced" but as "lines spent": the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger.
The quote is from an article called "On the cruelty of really teaching computing science".
It's a terrible metric, but as other people have noted, it gives you a (very) rough idea of the overall complexity of a system. If you're comparing two projects, A and B, and A is 10,000 lines of code, and B is 20,000, that doesn't tell you much - project B could be excessively verbose, or A could be super-compressed.
On the other hand, if one project is 10,000 lines of code, and the other is 1,000,000 lines, the second project is significantly more complex, in general.
The problems with this metric come in when it's used to evaluate productivity or level of contribution to some project. If programmer "X" writes 2x the number of lines as programmer 'Y", he might or might not be contributing more - maybe "Y" is working on a harder problem...
It's useful when loading up your line printer, so that you know how many pages the code listing you're about to print will consume. ;)
like most metrics, they mean very little without a context. So the short answer is: never (except for the line printer, that's funny! Who prints out programs these days?)
An example:
Imagine that you're unit-testing and refactoring legacy code. It starts out with 50,000 lines of code (50 KLOC) and 1,000 demonstrable bugs (failed unit tests). The ratio is 1K/50KLOC = 1 bug per 50 lines of code. Clearly this is terrible code!
Now, several iterations later, you have reduced the known bugs by half (and the unknown bugs by more than that most likely) and the code base by a factor of five through exemplary refactoring. The ratio is now 500/10000 = 1 bug per 20 lines of code. Which is apparently even worse!
Depending on what impression you want to make, this can be presented as one or more of the following:
all of these are true (assuming i didn't screw up the math), and they all suck at summarizing the vast improvement that such a refactoring effort must have achieved.
There are a lot of different Software Metrics. Lines of code is the most used and is the easiest to understand.
I am surprised how often the lines of code metric correlates with the other metrics. In stead of buying a tool that can calculate cyclomatic complexity to discover code smells, I just look for the methods with many lines, and they tend to have high complexity as well.
A good example of use of lines of code is in the metric: Bugs per lines of code. It can give you a gut feel of how many bugs you should expect to find in your project. In my organization we are usually around 20 bugs per 1000 lines of code. This means that if we are ready to ship a product that has 100,000 lines of code, and our bug database shows that we have found 50 bugs, then we should probably do some more testing. If we have 20 bugs per 1000 lines of code, then we are probably approaching the quality that we usually are at.
A bad example of use is to measure developer productivity. If you measure developer productivity by lines of code, then people tend to use more lines to deliver less.
Answer: when you can talk about negative lines of code. As in: "I removed 40 extraneous lines of code today, and the program is still functioning as well as before."
I'd agree that taking the total number of lines of code in a project is one way to measure complexity.
It's certainly not the only measure of complexity. For example debugging a 100 line obfuscated Perl script is much different from debugging a 5,000 line Java project with comment templates.
But without looking at the source, you'd usually think more lines of code is more complex, just as you might think a 10MB source tarball is more complex than a 15kb source tarball.
It is useful in many ways.
I don't remember the exact # but Microsoft had a web cast that talked about for every X lines of code on average there are y number of bugs. You can take that statement and use it to give a baseline for several things.
Another thing we look at is, why is it so many lines? Often times when a new programmer is put in a jam they will just copy and paste chunks of code instead of creating functions and encapsulating.
I think that the I wrote x lines of code in a day is a terrible measure. It take no account for difficulty of problem, language your writing in, and so on.
It seems to me that there's a finite limit of how many lines of code I can refer to off the top of my head from any given project. The limit is probably very similar for the average programmer. Therefore, if you know your project has 2 million lines of code, and your programmers can be expected to be able to understand whether or not a bug is related to the 5K lines of code they know well, then you know you need to hire 400 programmers for your code base to be well covered from someone's memory.
This will also make you think twice about growing your code base too fast and might get you thinking about refactoring it to make it more understandable.
Note I made up these numbers.
It's a metric of productivity, as well as complexity. Like all metrics, it needs to be evaluated with care. A single metric usually is not sufficient for a complete answer.
IE, a 500 line program is not nearly as complex as a 5000 line. Now you have to ask other questions to get a better view of the program...but now you have a metric.
It's a great metric for scaring/impressing people. That's about it, and definitely the context I'm seeing in all three of those examples.
Lines of code are useful to know when you're wondering if a code file is getting too large. Hmmm...This file is now 5000 lines of code. Maybe I should refactor this.
I wrote 2 blog post detailling the pro and cons of counting Lines of Code (LoC):
How do you count your number of Lines Of Code (LOC) ? : The idea is to explain that you need to count the logical number of lines of code instead of a physical count. To do so you can use tools like NDepend for example.
Why is it useful to count the number of Lines Of Code (LOC) ?: The idea is that LoC should never be used to measure productivity, but more to do test coverage estimation and software deadline estimation.
Always. Bunch o'rookies on this question. Masters write code prolifically and densely. Good grads write lots of lines but too much fluff. Crappers copy lines of code. So, first do a Tiles analysis or gate, of course.
LoC must be used if your org doesn't do any complexity points, feature points/function points, commits, or other analysis.
Any developer who tells you not to measure him or her by LoC is shite. Any master cranks code our like you would not believe. I've worked with a handful who are 20x to 200x as productive as the average programmer. And their code is very, very, very compact and efficient. Yes, like Dijkstra, they have enormous mental models.
Finally, in any undertaking, most people are not good at it and most doing it are not great. Programming is no different.
Yes, do a hit analysis on any large project and find out 20% plus is dead code. Again, master programmers regularly annihilate dead code and crapcode.
When you are refactoring a code base and can show that you removed lines of code, and all the regression tests still passed.
Lines of code isn't so useful really, and if it is used as a metric by management it leads to programmers doing a lot of refactoring to boost their scores. In addition poor algorithms aren't replaced by neat short algorithms because that leads to negative LOC count which counts against you. To be honest, just don't work for a company that uses LOC/d as a productivity metric, because the management clearly doesn't have any clue about software development and thus you'll always be on the back foot from day one.
When pointing out why the change is going to take so long.
"Windows is 7 million lines of code and it takes a while to test out all the dependencies..."
When the coder doesn't know you are counting lines of code, and so has no reason to deliberately add redundant code to game the system. And when everyone in the team has a similar coding style (so there is a known average "value" per line.) And only if you don't have a better measure available.
Check out wikipedia's definition: http://en.wikipedia.org/wiki/Source_lines_of_code
SLOC = 'source lines of code'
There is actually quite a bit of time put into these metrics where I work. There are also different ways to count SLOC.
From the wikipedia article:
There are two major types of SLOC measures: physical SLOC and logical SLOC.
Another good resource: http://www.dwheeler.com/sloc/
They can be helpful to indicate the magnitude of an application - says nothing about quality! My point here is just that if you indicate you worked on an application with 1,000 lines and they have an application that is 500k lines (roughly), a potential employer can understand if you have large-system experience vs. small utility programming.
I fully agree with warren that the number of lines of code you remove from a system is more useful than the lines you add.
I have found it useful under two conditions:
Gauging my own productivity on my own new project when it's heads down coding time.
When working with a large company and speaking with a manager that really only understands widgets per day.
First of all, I would exclude generated code and add the code of the generator input and the generator itself.
I would then say (with some irony), that every line of code may contain a bug and needs to be maintained. To maintain more code you need more developers. In that sense more code generates more employment.
I would like to exclude unit tests from the statement above, as less unit tests do generally not improve maintainability :)
The number of codes added for a given task largely depends on who is writing the code. It shouldn't be used as a measure of productivity. A given individual can produce 1000 lines of redundant and convoluted crap while the same problem could be solved by another individual in 10 concise lines of code. When trying to use LOC added as a metric, the "who" factor should also be taken into account.
An actually useful metric would be "the number of defects found against number of lines added". That would give you an indication of the coding and test coverage capabilities of a given team or individual.
As others have also pointed out, LOC removed has better bragging rights than LOC added :)
This is mostly an add to the already volumnous commentary.. But basically, lines of code (or perhaps totalCharacterCount/60) indicates the size of the monster. As a few people have said, that gives a clue to a codebase's complexity. It's level of complexity has a lot of impact. Partially it has impact on how difficult it is to comprehend the system and make a change.
That's why people want less lines of code. In theory, less lines of code is less complex, and there is less room for error. I'm not sure that knowing that upfront is terribly useful for anything other than estimation, and planning.
For example: Supposed I have a project and on cursory examination I realize that the matter will involve modifying as many as 1000 lines of code within an application that has 10,000 lines. I know that this project is likely to take longer to implement, be less stable, and take longer to debug and test.
It's also extremely useful for understanding the scope of change between two builds. I wrote a little program that will analyze the scope of change between any two SVN revisions. It will look at a unified diff, and from it, figure out how many lines were added, removed, or changed. This helps me know what to expect in the testing and QA that follows a new build. Basically, bigger numbers of change mean that we need to watch that build closer, put it through full regression testing, etc..
I heard that Microsoft used to fire 5% of people every 6 months, I always imagined it would be based on lines of code written, which is why Windows is so bulky, slow and inefficient ;). Lines of code is a useful metric for measuring the complexity of an application in terms of rough ordering, ie a beginners program in Basic might be 10 lines of code, 100 lines of code is a toy application, 50000 lines is reasonable size application, 10 million lines of code is a monstrosity called Windows.
Lines of code is not a very useful metric though, I used to write games in assembly language (68000 mainly) they would measure in at around 50k lines of code, but I kept the number of lines of code down by not pushing registers to the stack and keeping track of what was contained in the registers to cut down on code size (other programmers I knew did a push multiple of d0-d7,a0-a6 to the stack, which obviously slows down the code, but simplifies keeping track of what is affected).
It can be a very good measure of complexity for the purposes of risk assessment - the more lines changed the greater the chance of a bug being introduced.
Lines of code counts are useful when pitching the extensiveness of your comprehensive product to a customer who considers lines of code to be a general indicator of product size. For example, when you're trying to convince someone your product handles many corner cases, or when you're trying to get into a beta for a development tool where the tool vendor wants to get maximum code coverage for testing purposes.
Functionally never, aside from the previously-mentioned "bragging" purpose.
Lines != effectiveness. Often the relationship is inverse, in my experience (though not strictly, especially for the extreme, for obvious reasons)
