Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

How should I count the lines of code in a project?

In C++ for example, should I count the lines of the header files with my class definition? Should I count the header of a (non standard) library I am linking against?

In Qt (or any other GUI framework), should I count the lines of the form's design?

Should I count the Makefile too?

I ask because it is a simple way to measure the size of the project and/or effort involved. Even though a GUI file is not code per se the programmer might have spent hours doing it.

EDIT Most of you did not understand the question and/or are assuming that I want to use the magical number of LOC as the ONE AND ONLY metric to rate a project or even a day of work.

I consider a negative LOC day a very nice day. It means I've somehow managed to understand and model the problem better and more efficiently. Comments like "Why do you need this" are not interesting.

Like it or not, the number is out there, Wikipedia says Windows XP is rated at 45M LOC, Linux 2.6.35 at 13.5M, I could go on.

Maybe I could have asked better.

Anyway, my original intent was to know how those numbers in Wikipedia were calculated and not the subjective nature of them.

I found this in a MSDN blog, very useful as it shows how VS2008 does it:

enter image description here

share|improve this question
9  
Why do you need a line count? –  Tyanna Aug 11 '11 at 14:26
2  
Why not? It is a simple way to measure the size of the project. –  hexa Aug 11 '11 at 14:27
2  
It's not really all that simple, for the questions you've defined above and more. Do you count blank lines? If if you refactored something to take less lines of code, but it's more efficient? Is that good or bad? How do you reflect that in this metric? Perhaps looking at the number of screens produced, the number of classes written, and/or the table structure in the DB would give a better picture. –  Tyanna Aug 11 '11 at 14:33
13  
"Measuring programming progress by lines of code is like measuring aircraft building progress by weight." - Bill Gates –  BlackJack Aug 11 '11 at 15:08
2  
Programming is just a fancy form of typing, right? That's why I only hire programmers who can type 75WPM, productivity soars! –  JohnFx Aug 11 '11 at 16:05

9 Answers 9

You say it's a simple way to measure the size of a project. If you want to measure the size, why not just get the sum of the filesizes of all files that participate in the project? Or you could break it down by file types (headers, generated code, binaries such as image files, makefiles, etc...).

Measuring a project by the number of bytes it is vs. LOC helps you avoid problems where very simple lines of code (such as x=1; or {) get counted the same as very long lines. It's not perfect though, so you might want to take subcounts by different resource types, and also by number of resources of various types.

Measuring actual effort involved will never be the same as the size of the projet itself. What if 5 hours of effort were spent tweaking the values of 6 variables to get the behaviour just right? The total size of the project (by number of bytes or LOC or whatever) might not even change at all, but there was still effort spent to make changes.

share|improve this answer
1  
There are valid metrics that don't make much sense for file size. An example would be defects/LOC. Defects/byte really doesn't make much sense to me. Also, parametric estimation tools use SLOC - I believe both COCOMO and SLIM use LOC as an input, and it's fairly easy to build a historical project database and use existing projects to estimate LOC for future projects. –  Thomas Owens Aug 11 '11 at 19:58
    
@Thomas Owens: Good points. When I first answered this, I thought the OP just seemed to want some way to distinguish between "large", "medium" and "small" sized projects. The comments about effort came later, and I'm still not sure if OP actually plans to use these metrics for estimation, or still just to group things into "Large", "med", "Small". –  FrustratedWithFormsDesigner Aug 11 '11 at 20:01
1  
That makes sense. I didn't compare your post history to the post history of the question. –  Thomas Owens Aug 11 '11 at 20:08

For the most part, it doesn't really matter as long as you have a standard and are consistent among projects in the same programming language. You should generally create a document that explains how to count source lines of code and how to configure any tools that you use to use this method.

In C++ for example, should I count the lines of the header files with my class definition?

I would. You did write them after all, and they are used in the build process of your software.

Should I count the header of a (non standard) library I am linking against?

Yes, you can, if you are tracking code reuse. If you have the capability to count lines of code from other projects (either your own or open-source projects), you can consider that code reuse and use it when computing various reuse-related metrics.

In Qt (or any other GUI framework), should I count the lines of the form's design?

If you wrote them, I say yes. If they were automatically generated, then perhaps. If you do it once, you should do it consistently. Perhaps you want to consider counting generated code separately than hand-written code.

Should I count the Makefile too?

I would say no, as it's a supporting tool and not part of your built application. Again, going back to the GUI framework question, if it's autogenerated, perhaps you want to count it separately. Or perhaps you want to count "build scripts" separately and include things like Makefiles, Ant scripts, and so forth.

share|improve this answer
1  
+1: I was going to write the same. I don't agree with one of your points fully, though. Lines of code are a measurement to roughly determine the size of a project. If you don't count autogenerated GUI code, then that falsifies the whole metric for GUI applications. After all, the forms mostly were created with some sort of designer and serious effort has been put into them. I'd count makefiles, too, but I use a tool (cloc) which can differentiate between code-types and list them separately. –  Falcon Aug 11 '11 at 15:07
    
@Falcon I personally would count autogenerated code, but isolate it from hand-written code, as in count them separately. If you write code by hand, you really need to count it and there's no option. It becomes a little more vague for generated tools, and the important thing is consistency. –  Thomas Owens Aug 11 '11 at 15:36
1  
Like Falcon said, I just use CLOC to count lines of code. –  Brian Cable Aug 11 '11 at 19:28

How should I count the lines of code in a project?

If this is just a rough measure of work then all I would do is:

# This assumes you build obj/lib/executables into a seprate tree hierarchy
find . | xargs wc -l

In C++ for example, should I count the lines of the header files with my class definition? Should I count the header of a (non standard) library I am linking against?

I would count everything in your source tree that you build. But not the stuff that you link against (you can count that separately).

In Qt (or any other GUI framework), should I count the lines of the form's design? Should I count the Makefile too?

Any thing that is part of the project that involved effort to write should probably be counted. If there is something really huge that took no effort I may manually remove its count from the total. But this is not something I would spend a lot of time on working out what the best things to count are.

share|improve this answer

Software metrics are, generally, a fairly subjective wreck massively open to interpretation and reinterpretation. Probably the only really meaningful one to an outsider is defects filed per year per release.

Lines of code will vary between programmers, languages, commenting style, bracing style, corporations, and levels of experience.

Of course, the more you write, the more bugs have a chance to surface, so LoC growth is proportional to the potential number of bugs.

That said:

wc -l *.lisp

is how I count my LoC, and it serves as a rough metric of "how much work have I done".

Another way is churn, which is the # of added, removed, and modified lines over time in a codebase. That can be extracted from your version control system.

share|improve this answer

There is no perfect way to count code. Find a method and use it, and use it consistently. If you use one mechanism for one project and a different mechanism for another project, the numbers mean nothing. If you use the same system for all of your projects, the numbers still mean nothing but at least they give you a rough idea of the project size relative to each other.

share|improve this answer

Many people have reacted somewhat negatively to this question. I would, instead look upon it as an opportunity.

Nearly the only reasonable excuse for counting lines of code is that it's been demanded by somebody higher up the food chain (who's clearly clueless, or he wouldn't ask for that). As such, you should get that person involved -- preferably doing something like heading a committee (that includes as many of the least useful of your co-workers as possible) researching the most efficacious way(s) to count lines of code.

As far as the specific method itself, such momentous decisions obviously require the input of the entire committee. Your job is to supply them with plenty of raw data, measuring lines of code every which way you can (at least without expending any more than a minimum of effort). You should, however, meter the rate at which you supply them with this information -- if, heaven forbid, they get close to a final decision, you need to give them an exciting new option that forces them to go back to the drawing board to spend at least a few more months studying the problem and considering how best to incorporate this new option into a company-wide line-counting strategy!

This has two good effects. First of all, it obviously distracts them from other things that are likely to be more harmful to productivity. Second, you can bolster their self esteem by supplying them with at least a little data that they will eventually realize is even more worthless than the rest, so when they write their three-volume guideline on the proper ways to count lines of code, they can make some good, solid recommendations about at least a few things to avoid, so at the end of it all they can really know they've accomplished something useful. In addition, they will have shown you mere peons that without their brilliant, seasoned leadership, you'd be making all sorts of foolish mistakes in this most crucial of tasks.

Lest you should mistake this for being entirely facetious, I'll point out that this really is quite important -- without something like this to occupy their time, they'll start to study something like ISO 9001 conformance. The minute they decide to go ahead with something like that, you might as well write off at least a solid month that will be dedicated to writing up detailed documentation of how you do your job (which, to give you any hope of passing an inspection, will end with something like: "and if none of that works, we will exercise our judgement and do what seems reasonable.") With a little care in its application, a small investment in line counting software can prevent, or least delay, such disasters for a considerable time.

share|improve this answer

Not sure if this qualifies as an answer, but I think the way you count lines of code should depend on the language used. And maybe you should think of using an alternative measurement, like the percentage of project requirements satisfied.

I worked on a perl project several years ago, and as I added features the code line count actually went down because of code reuse and other factors. So the project at 50% complete actually had more lines of source code than the project at 100% complete.

Perhaps you should count the total lines of code written, and so the count would always go up, because even when you refactor code, and perhaps reduce the line count, you are creating new lines of code to replace the old ones.

share|improve this answer

Sorry, I can't resist the Dijkstra quote:

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.

Look, if you really must count lines, just use wc -l, apply a fudge factor, and if anybody knows a better way, let them do it !

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.