Jump to content

Source lines of code

From Wikipedia, the free encyclopedia
This is an old revision of this page, as edited by Dwheeler (talk | contribs) at 21:44, 12 August 2003 (New article!!). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.
(diff) ← Previous revision | Latest revision (diff) | Newer revision → (diff)

Source lines of code (SLOC) is a software metric used to measure the amount of code in a software program. SLOC is typically used to estimate the amount of effort that will be required to develop a program, as well as to estimate productivity or effort once the software is produced.

There are two major types of SLOC measures: physical SLOC and logical SLOC. Specific definitions of these two measures vary, but the most common definition of physical SLOC is a count of "non-blank, non-comment lines" in the program's source code. Logical SLOC measures attempt to measure the number of "statements", but their specific definitions are tied to specific computer languages (one simple logical SLOC measure for C-like languages is the number of statement-terminating semicolons). It is much easier to create tools that measure physical SLOC, and physical SLOC definitions are easier to explain. However, physical SLOC measures are sensitive to logically irrelevant formatting and style conventions, while logical SLOC is less sensitive to formatting and style conventions. Unfortunately, SLOC measures are often stated without giving their definition, and logical SLOC can often be significantly different than physical SLOC.

Even the "logical" and "physical" SLOC values can have a large number of varying definitions. Robert E. Park et al. developed a framework for defining SLOC values, to enable people to carefully explain and define the SLOC measure used in a project. For example, most software systems reuse code, and determining which (if any) reused code to include is important when reporting a measure. SLOC measures are somewhat controversial, particularly in the way that they are sometimes misused. Experiments have repeatedly confirmed that effort is highly correlated with SLOC, that is, programs with larger SLOC values take more time to develop. Thus, SLOC can be very effective in estimating effort. However, functionality is less well correlated with SLOC: skilled developers may be able to develop the same functionality with far less code, so one program with less SLOC may exhibit more functionality than another similar program. In particular, SLOC is a poor productivity measure of individuals, since a developer can develop only a few lines and yet be far more productive than a developer creating lines of code for the sake of creating a larger number. Good developers may merge code modules into single module, improving the system yet appearing to have negative productivity because they remove code, and skilled developers tend to be assigned the most difficult tasks.

There are several cost, schedule, and effort estimation models such as the COnstructive COst MOdel (COCOMO) series of models by Barry Boehm et al., which use SLOC as an input parameter. While these models have shown good predictive power, they are only as good as the estimates (particularly the SLOC estimates) fed to them. Many have advocated the use of function points instead of SLOC as a measure of functionality, but since function points are highly correlated to SLOC (and cannot be automatically measured) this is not a universally held view.

According to Gary McGraw, the SLOC values for various versions of Microsoft's Windows operating system are as follows (estimating from his graph; he does not specify if these are physical or logical measures or a mixture):

YearOperating SystemSLOC
1990Windows 3.13</td
1995Windows NT4
1997Windows 9515
1998Windows NT 4.016
1999Windows 9818
2000Windows NT 5.020
2001Windows 200035
2002Windows XP40


References: