I know many despise KLOC as some managers attempt to correlate that with productivity. But when we speak only comparing sizes of projects using the same languages and coding standards as well as the same tool for LOC calculation. Unlike story points, this seems like a more reasonable way that size of two projects can be compared.

  • Depends what you want to compare - if you literally wants to compare the size of the project source code, it is a fine measurement. But if you want compare things like complexity or amount of work then it only makes sense if the two code bases have been written by the same people in the same language on the same platform.
    – JacquesB
    Oct 9 '18 at 7:50
  • @JacquesB It can used to normalize e.g. defect count, as used in Defect density.
    – John V
    Oct 9 '18 at 7:54
  • 9
    It is like asking "is it OK to compare people by weight"? Well yes you can do that...the question is what conclusion you want to draw from that comparison. If you literally want to know if one person is bigger as another, then comparing by weight is fine. The problem is when people draw conclusion like assuming weight corresponds to efficiency at work or something like that. So the question is what conclusion you want to draw based on this comparison.
    – JacquesB
    Oct 9 '18 at 8:53
  • How could you compare the size of a project using story points? Story points are used to estimate the time to to accomplish a piece of work relative to some other pieces of work. They aren't a measure of size, and I've never heard someone using them to compare the size of two projects. Oct 9 '18 at 15:54
  • @ChrisCooper Actually some do that. SPs are about effort mainly, and as such you might get a relative size of a project by considering all the estimated efffort. if project A takes 2000 SP and project B 500 SP, you can be sure it is roughly a quarter. But it only works if the same reference stories are used for estimation.
    – John V
    Oct 9 '18 at 16:16

The answer to this question will depend on your coding standards. The stricter they are, the less variation there can be in code produced by two developers, thus the closer the KLOC count will be for the same solution from different people.

But let's assume you work for a company that doesn't mandate every last detail and allows a degree of self-expression when writing code. To take an example, consider the following two ways of writing a method in C# for the fizzbuzz game:

Version 1

IList<string> GenerateFizzBuzzList()
    var fizzBuzz = new List<string>();
    for (var i = 1; i <= 100; i++)
        var entry = "";
        if (i % 3 == 0)
            entry += "Fizz";
        if (i % 5 == 0)
            entry += "Buzz";
        if (entry == "")
            entry = i.ToString();
    return fizzBuzz;

Version 2

IList<string> GenerateFizzBuzzList()
    var fizzes = Cycle("", "", "Fizz");
    var buzzes = Cycle("", "", "", "", "Buzz");
    var words = fizzes.Zip(buzzes, (f, b) => f + b);
    var numbers = Range(1, 100);
    return numbers.Zip(words, (n, w) => w == "" ? n.ToString() : w).ToList();

Both solutions are written in the same language (C#). Both solutions follow the same rules on naming, brace layout and various other conventions (eg using var) that are common in coding standards. Yet version 1 is nearly three times the size of version 2.

Scale these two approaches up to a moderately large app and we might have 80,000 lines in one project and 220,000 in another. But that 140,000 line difference is purely down to the approach taken, rather than because one does more than the other. KLOC can only tell you the comparative size of functionality if exactly the same approach to writing code is adopted for each project. In reality, exactly the same approach is only used by poor quality devs who never learn new techniques and ways of expressing code, ie in reality KLOC is just a measure of the number of lines of code. It measures nothing else so is of no use in trying to measure anything else.

  • 5
    @Christophe, I disagree. No amount of empty line removal and pretty printing will achieve Loc parity between my examples. Example 1 contains over 50% more statements and expressions, which is as close as you could get them to each other. 50% difference still makes a mockery of Loc being a useful measure of anything except Loc.
    – David Arno
    Oct 9 '18 at 11:07
  • 2
    @Christophe: To use your analogy: KLOC is like counting a distance in paces, not kilometers. Not everyone's paces are the same, and therefore it's a futile effort to guess whether you or I travelled the furthest distance, based solely on the knowledge that I took X paces and you took Y paces (= it's pointless to compare code bases based solely on their KLOC). Only when you know that our paces are the same length (= normalizing the coding standard between the code bases) can you use paces as a measure for distance.
    – Flater
    Oct 9 '18 at 13:53
  • 1
    @JohnV: there is nothing else to measure or at least estimate size Why try to express it in function of size to begin with? It's not about size, it's about complexity. As a very basic (and massively oversimplified) counterexample, it would be more meaningful to compared compiled IL size instead of source code size, as it removes the factor of coding style and focuses solely on the required functionality.
    – Flater
    Oct 9 '18 at 14:06
  • 1
    "The second example strikes me as the kind of tossing and turning that happens when those enamored with Linq want to use it for everything". It's called "declarative programming". It has numerous advantages, in that it mutates no variables and is simpler to reason for many folk. But others do indeed see it as "tossing and turning" for they prefer imperative programming. Each to their own and completely off-topic for this question.
    – David Arno
    Oct 9 '18 at 15:17
  • 3
    @Christophe: You misunderstood the term "paces" as Flater used it. Pace was used with the meaning "a single step taken when walking or running." How many meters are there in one pace? Oct 9 '18 at 15:31

Why are KLOC still in use ?

KLOC is neutral measure of the size of code, just as kilometers are a neutral measure of distance.

And just as KLOC, kilometers are not very useful: a larger number of km does not guarantee that the journey is nicer, more pleasant or with more sightseeing. Kilometers are also a bad predictor: they are not telling you how long it will take to reach the target, and neither how much fuel you'll need.

Yet, kilometers are still the main unit of measure for distance. And certainly for similar reasons, KLOC are still in use for size measurement.

What do you want to measure with KLOC ?

KLOC is a (very) bad indicator for productivity: writing a nice reusable and maintainable classes/functions can result in much smaller code, than dumb copy/paste/edit and repeating oneself for ever. But shorter code in same time might appear as less productive, although it's quite the contrary on the long run, since you'll need to code less thanks to reuse, and you'll need to test less, as you can rely on already tested components.

But KLOC is a valid measure of size. As every unit of measure, it has some shortcomings: not all lines are of same complexity, and layout and style can influence the quantity. But with some normalisation (such as ignoring empty lines and comment lines, or applying some pretty printing to neutralize style differences), over a large code base, it will have some statistical meaning.

Size only measures a quantity. It can influence compile time or reviewing time. It is used in litigations on intellectual property, to measure the degree of similarity between two different source codes. But don't expect it to be a good predictor of time, effort, or complexity (10 liens of recursive code are still more complex than 50 lines of sequential satements).

What are the alternatives ?

Story points are subjective to the team that made evaluation: you can't know for sure if this metric corresponds to size or to effort.

There are also function points that aim at more objectivity. But these are not readily available from the code and require an expensive analyse with also some room for interpretation (although less than with story points). I am also not sure they are still relevant in an OO worlds with GUIs.

Story points and function points are anyway estimates of requirements and expected features. They are evaluated before the code is written, and will in general not be updated if they appear to be inaccurate. They may give an idea of the complexity, but not at all of the size of the code that will be produced.

  • Even though most books consider story points indicative of effort, they are still relative to the team. So I could not compare two projects as 5 SP for Project A might mean 2 SP for project B.
    – John V
    Oct 9 '18 at 7:28
  • @JohnV you may find interesting material on the web site to which I linked for story points: there are several other articles about story point vs. ideal days and work hours. You may use some kind of correction factors between so from different teams, but how can you ensure it's reliable ? And are the sp estimates updated if it turns out that a story was more difficult than expected ? And if you take into account burn-down of the respective team, how will you make the difference between the sp estimate error, and the level of performance of the team (which both impact burn-down rate).
    – Christophe
    Oct 9 '18 at 8:01
  • I know that website but exactly for reasons you mention, I do not think I can compare different teams and their SP estimate (one can estimate whole product for 200, the other for 400..)
    – John V
    Oct 9 '18 at 8:06
  • @JohnV so in the end, the main question will be: what do you really want to measure and for which purpose ? And a complementary question: how accurate have your statistic findings to be ? (Hint: the accuracy requirement might not be the same depending on whether you're doing reliability prediction on thousands of projects for the pentagon, or if you're predicting customer satisfaction based on defect rate of a few company projects).
    – Christophe
    Oct 9 '18 at 8:11
  • Well with normalized size, I can look at things like number of critical defects and can compare across projects. So the number is jsut indicative.
    – John V
    Oct 9 '18 at 8:17

The problem with LoC for estimation is that you dont know in advance how many lines the final code will contain.

In terms of a post measure of the complexity and size of a project its as good as any other measure.

Assuming that people have a style of coding that they generally stick to and a speed at which they generally type. Then yes, you can look back at the code they wrote and see which tasks were easy and which were hard by the final LoC and the time it took for the dev to write them compared to their average speed.

This doesnt really help you in estimating future work though.

  • According to the many comments it turns out that OP is not interested in estimating future work, but in comparing number of bugs with the size of code. I suppose the aim is to see if some projects are more buggy than others in relative terms.
    – Christophe
    Oct 9 '18 at 18:16

You're confusing two entirely different things here.

Managers care about functionality, because that's what marketing has sold. They don't care about project size at all except as an indicator for completeness of functionality. It's a very, very weak indicator, and only bad managers rely on it if there's anything better available, but it happens.

Programmers care about project size because that determines how hard the code base is to handle. They don't (primarily) care about functionality except insofar as that is what pays their checks. Unlike managers, programmers would prefer a smaller code base, other things being equal.

This means that the two situations are not comparable at all. KLOC is a useful measure to judge project size, and a very useless measure to judge completeness or productivity. There is no contradiction here.

  • 1
    No, managers often (and you ran read many experiences of the others) think that the more you write, the more productive you are. Thus people are more expressive in order to inflate their SLOC.
    – John V
    Oct 9 '18 at 7:15
  • you mean the more you write per day
    – Ewan
    Oct 9 '18 at 7:43
  • @Ewan Not just per day. Some want to know who wrote how much and equate that to productivity.
    – John V
    Oct 9 '18 at 7:53
  • 1
    obviously given unlimited time you can write unlimited lines of code. productivity is a time based metric
    – Ewan
    Oct 9 '18 at 7:55

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