CodeBetter.Com
CodeBetter.Com
RSS 2.0 via Feedburner
           Do you Twitter? Follow us @CodeBetter

Patrick Smacchia [MVP C#]


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

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. More info about sequence points here. 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.


Comments

Tim B said:

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.

# October 4, 2007 5:47 PM

keith said:

tim took my answer :[

# October 4, 2007 7:12 PM

Patrick Smacchia said:

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.

# October 5, 2007 1:19 AM

Patrick Smacchia [MVP C#] said:

My previous post explained How to count the LOC of your .NET application and Tim B and Keith answered

# October 5, 2007 2:25 AM

Jeff B said:

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.

# October 6, 2007 3:31 PM

Patrick Smacchia [MVP C#] said:

There has been recently some discussion about Code size is the enemy starting from (in order of publication

# December 25, 2007 2:15 PM

Code Metrics with Visual Studio 2008 « SYNDATO GmbH said:

Pingback from  Code Metrics with Visual Studio 2008 « SYNDATO GmbH

# May 16, 2008 6:43 AM

Leave a Comment

(required)  
(optional)
(required)  

Enter the numbers above:
Add

About Patrick Smacchia

Patrick Smacchia is a Visual C# MVP involved in software development for over 15 years. After graduating in mathematics and computer science, he has worked on software in a variety of fields including stock exchange, airline ticket reservation system as well as a satellite base station at Alcatel. He's currently a software consultant and trainer on .NET technologies as well as the lead developer of the tool NDepend which provides numerous metrics and caveats on any compiled .NET application. He is the author of Practical .NET2 and C#2, a .NET book conceived from real world experience with 647 compilable code listings. Check out Devlicio.us!