How do you count your number of Lines Of Code (LOC) ?

Posted by Patrick Smacchia on October 3, 2007

Do you count method signature declaration? Do you count lines with only bracket? Do you count several lines when a single method call is written on several lines because of a high number of parameters? Do you count ‘namespaces’ and ‘using namespace’ declaration? Do you count interface and abstract methods declaration? Do you count fields assignment when they are declared? Do you count blank line?

Depending on the coding style of each of developer and depending on the language choose (C#, VB.NET…) there can be significant difference by measuring the LOC.

Apparently measuring the LOC from parsing source files looks like a complex subject. Thanks to an astute there exists a simple way to measure exactly what is called the logical LOC. The logical LOC has 2 significant advantages over the physical LOC (the LOC that is inferred from parsing source files):

  • Coding style doesn’t interfere with logical LOC. For example the LOC won’t change because a method call is spawn on several lines because of a high number of arguments.
  • Logical LOC is independent from the language. Values obtained from assemblies written with different languages are comparable and can be summed.

In the .NET world, the logical LOC can be computed from the PDB files, the files that are used by the debugger to link the IL code with the source code. The tool NDepend computes the logical LOC for a method this way: it is equals to the number of sequence point found for a method in the PDB file. A sequence point is used to mark a spot in the IL code that corresponds to a specific location in the original source. Notice that sequence points which correspond to C# braces‘{‘ and ‘}’ are not taken account.

Obviously, the LOC for a type is the sum of its methods’ LOC, the LOC for a namespace is the sum of its types’ LOC, the LOC for an assembly is the sum of its namespaces’ LOC and the LOC for an application is the sum of its assemblies LOC. Here are some observations:

  • Interfaces, abstract methods and enumerations have a LOC equals to 0.
  • Only concrete code that is effectively executed is considered when computing LOC.
  • Namespaces, types, fields and methods declarations are not considered as line of code because they don’t have corresponding sequence points.
  • When the C# or VB.NET compiler faces an inline instance fields initialization, it generates a sequence point for each of the instance constructor (the same remark applies for inline static fields initialization and static constructor).
  • LOC computed from an anonymous method doesn’t interfere with the LOC of its outer declaring methods. The overall ratio between NbILInstructions and LOC (in C# and VB.NET) is usually around 7.


This entry was posted in Lines of Code, LoC. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • .

    I need to find an error on line 3402, and there is no fucking way I’m going to count them all by hand!

  • PeteB

    I have to say I am shocked (and sadened) that counting SLOC is considered a Dilbert-like activity. If I am trying to estimate effort for any activity, design, coding, testing, intergration, I need to have some idea of the scale of the thing under development. If I don;t have SLOC as ONE PART of my data set, it becomes an effort of useless guesswork. I work with many (over 200) high maturity organizations – they measure SLOC. Stop bitching you babies!

  • Andrew D

    This is foolish.

    Counting lines of code is completely trivial, and really measures nothing.

    Let’s say that there’s a requirements document that outlines some specs for software to be built. Let’s also say we give the same requirements docs to two different programmers that don’t know about each other, and are equally weird looking.

    Let’s pretend this happens:

    Programmer A: Writes 2500 total lines of code in 3 files, in 5 days. 5 bugs are filed by QA. Bugs are fixed and code passes testing in 8 days total with QA’s seal of approval.

    Programmer B: Writes 500 total lines of code in 12 files in 8 days. 2 bugs are filed by QA. Bugs are fixed and code passes testing in 10 days total with QA’s seal of approval.

    Both pieces of software meet the requirements.

    It’s easy to see why management propagates the “more lines is more better” myth in cases like this. It looks like 2 days were saved by Programmer A!

    But wait, there’s more. More often than not I’ve seen this happen:

    Programmer A wrote software that is a nightmare to maintain. It’s hacked together and excruciating to debug, especially when Programmer C is tasked to maintain the code when Programmer A eventually quits to become a development manager at Microsoft.

    Programmer B wrote software that is generic and extensible, reusable and well-documented. Programmer C can learn from the code, extend it, improve it, even refactor it. All because Programmer B spent an appropriate amount of time designing the software with the future in mind.

    Lines of code really are irrelevant. Quality of code designed is relevant.

  • Fred

    Jeff B,

    If lines of code are the only way that you can tell a good developer from a bad one then you are obviously not a developer but rather just the know-nothing turd that your comments make you appear to be.

  • Theo

    JeffB,

    people like you caused the economic crisis. And people like you are the first ones to go on a crisis.
    My regards.

  • clint

    The sequence points link doesn’t work.

  • Jeff B

    Tim / Keith,
    Predictable egotistical and immature responses from typical hackers who always insist that any measure of productivity (what other profession gets away with this attitude?), even if used to justify better tools, environments and processes to your benefit, would be an insult to your so-called craft (which is being commoditized every day by offshore developers). If you acted like you knew or cared anything about business you might actually have something to contribute to society 5-10 years from now when programming is a thing of the past.

    Counting LOCs, defects, story cards, hours, and other measures are the only way to tell a good developer from a bad and/or lazy one.

    Cheers.

  • http://www.NDepend.com Patrick Smacchia

    I don’t agree, LOC is far from being meanlingless.

    Yes the LOC is not directly related to productivity ans should never be used as a yardstick.

    However it is a the simpler way to coarsly measure the overall endeavour put in an application and to compare them. For example the codebase I am working on is 50K LOC while the .NET framework is around 500K LOC. Then, I have a pretty clear idea of the overall size of the framework.

    Also LOC is useful when you have to plan some refactoring, or some migration because it will helps estimate the delay. If your team need a month to refactor X lines, it’ll take around 2 months to refactor 2X LOC.

  • http://www.afex2win.com keith

    tim took my answer :[

  • http://bigtunatim.wordpress.com Tim B

    I follow this easy rule of thumb: don’t count them. And if it’s required of me, I make up a reasonable number and begin looking for a new employer that is interested in code quality rather than meaningless metrics.