Counting lines of code and comments is sometimes bogus, since most of what we write may be written in one or more lines, depending column count limitations, screen size, style and so forth.

Since the commonly used languages (say C, C++, C# and Java) are free-form, wouldn't it be more clever to count characters instead?

Edit: I'm not considering LOC-oriented programming where coders try to artificially match requirements by adding irrelevant comments or using multiple lines where less would be enough (or the opposite). I'm interested in better metrics that would be independent of coding style, to be used by honest programmers.

closed as not constructive by user8 Oct 26 '11 at 14:13

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance. If this question can be reworded to fit the rules in the help center, please edit the question.

  • Almost any metric can be gamed. There are books written on this topic. – Jamie F Oct 26 '11 at 13:37
  • 10
    I'm confused why you'd be concerned with counting anything? If it's well-formed, working code - does it matter? Do people get paid by the line? If so, I have some veeeeeeeeeeeeeeerry verbose code I'd like to submit for $$$. – Yatrix Oct 26 '11 at 13:40
  • 1
    Maybe my boss wants to know the size of the project to decide whether to allocate more people to it (If my boss actually though that way, I'd spit in his face, though). Maybe I'm trying to get the LOC down. Maybe I'm curious about the comment/code ratio. Maybe I want to have a rough idea of the complexity of a program written in two different languages. Etc. – Gabriel Oct 26 '11 at 13:50
  • 3
    None of these counts have any context. You won't know whether something was done well until you review the code anyway. Again, a count is just "how many", not "how well". Proper planning and code reviewing is a better course than concerning yourself with Any count. Just my 2 cents...well, in this economy, it's only worth about .75 cents. =) – Yatrix Oct 26 '11 at 13:55
  • Wouldn't counting characters be pointless in the face of automatic refactoring tools? Or maybe you'd have to first refactor all symbols to their shortest possible length (so one or two characters in most local scopes) and then count characters... or maybe count the number of variables used, classes/modules used, and functions used, regardless of symbol-name length. – FrustratedWithFormsDesigner Oct 26 '11 at 13:57

Counting lines of code and comments is sometimes bogus, since most of what we write may be written in one or more lines, depending column count limitations, screen size, style and so forth.

When doing anything with lines of code, you need a consistent definition of what a "line of code" is, exactly. You need to know if you are counting physical lines of code or logical lines of code and what exactly makes up a "line of code".

As an example:

for (int i = 0; i < array.length; i++) {
  boolean truthValue = processElement(array[i]);

  if (truthValue) {

That could be considered 6 physical lines, 4 logical lines, or something else entirely.

In addition, you need rules on a per-language basis, based on coding style that can be consistently applied across projects. It's a fact that 3 lines of Python is not equal to 3 lines of Java is not equal to 3 lines of Objective-C. However, 3 lines of Python always needs to be 3 lines of Python, 3 lines of Java always needs to be 3 lines of Java, and 3 lines of Objective-C always needs to be 3 lines of Objective-C.

Also, comments and code should be counted separately. For example, in a comment, I mentioned that a line of code can be used in Six Sigma as an "opportunity". A non-executable component should not be included in that. In addition, comparing a ratio of comments/lines of code isn't necessarily meaningful as well-organized code should need fewer comments to begin with. I'd be much more careful with counting comments than counting code, other than identifying a distinct lack of comments (especially in public APIs or systems that use automatic documentation generation) or excessive comments as those are opportunities to improve documentation or refactor (or remove useless, potentially out-of-date comments).

Since the most used languages (say C, C++, C# and Java) are free-form, wouldn't it be more clever to count characters instead?

I don't think so. Cleverness buys you nothing - if you try something clever, you are likely shooting yourself in the foot, either with other people trying to understand your intentions. You should keep it simple. The line and the statement are the most fundamental building blocks of a unit of code. Every language has a concept of a statement - a single, meaningful, block. Your coding style should specify how to format your statements into lines. Thus, making both statements and lines consistent measurements across projects (written in the same language) to compare.

  • Is my code formatted weird for anyone else? If it is, could someone try to fix it. – Thomas Owens Oct 26 '11 at 14:00
  • Wow, you did not mention that my question was stupid, and at the same time you provided a detailed, motivated and relevant alternative ! Thx (: – Gabriel Oct 26 '11 at 14:02
  • 2
    @Gabriel Because it's not a stupid question. Asking what to measure or calculate is a component of empirical software engineering and software quality. – Thomas Owens Oct 26 '11 at 14:03
  • 2
    "Measuring programming progress by lines of code is like measuring aircraft building progress by weight." Bill Gates – Jaydee Feb 17 '12 at 14:00

Seeing LOC is a bad metric, I would say the number of characters and/or comments is just as bad, if not worse.

If you start measuring by number of characters, you will get very very long identifiers.

If you start measuring by number of comments (or characters in comments), you will get lots of irrelevant comments with loads of padding (I can imagine getting whole literary expositions).

  • 2
    LOC is not a bad metric, but rather misused. It's actually not even a metric at all, but a measurement. For example, calculating productivity in LOC/time is a bad metric, but defects/LOC can be used to apply Six Sigma to software (Six Sigma -> around 3-4 defects per million opportunities, where a software "opportunity" could be a line of code), given a consistent definition of a "line of code" (physical versus logical). – Thomas Owens Oct 26 '11 at 13:44

Forget either approach. Count the number of user acceptance tests that pass.

Very clever.


Not necessarily, since you would motivate people to write really, really, really, really long variable names and thereby obfuscate the code. A line maps to a statement in many coding styles, so it is often a better indicator of the amount of code.

You could of course go by words of code (WOC) to remedy that. But I don't think that any code metric based on the output of wc is any better than the other, and all are pretty bad.


Why does this matter, exactly?

Has anyone ever said an application sucks because it only has x number of lines? Neither matter unless for some reason writing MORE code is a bragging right I'm not aware of. Personally, the less code you write is a better practice, if it's just as readable.

Clever? Counting characters may be the least clever thing ever. Ever.

  • I'm personnally using LOC count to check whether my code is bloated. When going up too much, I try refactoring to get the LOC down. – Gabriel Oct 26 '11 at 13:41
  • 1
    @Gabriel, then make that your question instead of some ridiculousness about counting LOC without providing a proper context. – Anthony Pegram Oct 26 '11 at 13:43
  • 2
    No count will tell you that. Code review, or just looking over your OWN code and refactoring it after stepping away for a day will be better suited. I often come back to code I wrote a month ago and think "Really? That's what I did? I'm a jackass." Some methods will just require 100 lines. That doesn't mean it should or COULD have been done in 75. – Yatrix Oct 26 '11 at 13:46

Everyone knows that such metrics are flawed and can be cheated.

That said, when I count lines of code in my C programs, I actually count semicolons, i.e., actual number of statements.

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