“I'm sorry, Dave. I'm afraid I can't do that” – HAL 9000[1]
Source lines of code (SLOC) is a measure of software size, in use since the 1960s. This blog post describes various uses of SLOC from the perspective of software measurement.
There seems to be a love/hate relationship with the line of code measure. Despite its broad and continuous use (or perhaps because of it) SLOC seems to get the blame for many a failed software project, process improvement or software metrics initiative. There are even those who claim that “…in many situations usage of LOC metrics can be viewed as professional malpractice…”[2] But, as you will see, SLOC has many benefits, when used intelligently.
The purpose of SLOC in a measurement practice is simply to capture software size. Nothing else. Because of this purity, SLOC can be combined with other measures and software cost estimating relationships to estimate effort, duration or productivity (more in a future post). Because of early misuse of SLOC, all sorts of alternatives to SLOC (e.g., Function Points and more than 35 variants, Story Points, Object Points, Use Cases and many, many others) were invented in an attempt to “fix” SLOC, but in the end these only complicated matters. Most of these measures try to accomplish too much. They include concepts such as functionality, complexity, user behavior or elements of architectural design. As a result, only a few of these measures survive today. And none have the simplicity, understandability or clarity of intent that SLOC enjoys. In fact, no other measure better answers the question: How much code?
The much-maligned SLOC measure has been defined and redefined many times over the years, but in practice, the definition of SLOC falls into one of two broad categories: physical source statements or logical source statements. Both definitions typically exclude blank lines, comments and non-delivered code.
Many programming languages allow one statement to be divided into more than one physical line, as the following code example illustrates:
Likewise, multiple statements may be combined onto a single physical line:
Regardless of coding style, both definitions have value. That said, the software industry has pretty much decided that logical SLOC is better than physical SLOC, when using SLOC as a proxy for effort.
Much more important than a precise definition of SLOC (or any measure), however, is its consistent usage in a measurement program. Even if you used the worst definition of SLOC known to humanity, but you use it consistently, you would be better off than using the SLOC definition currently in vogue, and changing with the times. By sticking with consistent measures, comparisons between projects (across all time) and trends within a project are much easier to observe.
Next: estimating effort, duration and productivity by combining SLOC with other measures and cost estimating relationships.
[1] 2001, a Space Odyssey. Dir. Stanley Kubrick. Metro-Goldwyn-Mayer, 1968.
[2] Jones, Capers, “A Short History of Lines of Code (LOC) Metrics,” Version 2.0, May 10, 2008