Standard/Proper way of counting lines of code?

Question

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:

Answer 1

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.

Answer 2

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.

Answer 3

You should probably look here for your answer:

http://en.wikipedia.org/wiki/Source_lines_of_code

http://msquaredtechnologies.com/m2rsm/docs/rsm_metrics_narration.htm

Answer 4

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.

Answer 5

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.

Answer 6

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.

Answer 7

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.

Answer 8

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.

Answer 9

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 !