Source lines of code
295066
226135828
2008-07-16T23:50:57Z
213.39.155.183
/* Freeware (Closed source) */
'''Source lines of code''' ('''SLOC''') is a [[software metric]] used to measure the size of a [[Computer software|software program]] by counting the number of lines in the text of the program's [[source code]]. SLOC is typically used to predict the amount of effort that will be required to develop a program, as well as to estimate [[programming productivity]] or effort once the software is produced.
==Measuring SLOC==
Many useful comparisons involve only the [[order of magnitude]] of lines of code in a project. Software projects can vary between 10 to 100,000,000 or more lines of code. Using lines of code to compare a 10,000 line project to a 100,000 line project is far more useful than when comparing a 20,000 line project with a 21,000 line project. While it is debatable exactly how to measure lines of code, discrepancies of an order of magnitude can be clear indicators of software complexity or [[man hours]].
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 lines in the text of the program's source code including comment lines. Blank lines are also included unless the lines of code in a section consists of more than 25% blank lines. In this case blank lines in excess of 25% are not counted toward lines of 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 (programming language)|C]]-like [[programming language]]s 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 from physical SLOC.
Consider this snippet of C code as an example of the ambiguity encountered when determining SLOC:
<source lang="c">
for (i=0; i<100; ++i) printf("hello"); /* How many lines of code is this? */
</source>
In this example we have:
* 1 Physical Lines of Code LOC
* 2 Logical Lines of Code lLOC (for statement and [[printf]] statement)
* 1 Comment Line
Depending on the programmer and/or coding standards, the above "line of code" could be, and usually is, written on many separate lines:
<source lang="c">
for (i=0; i<100; ++i)
{
printf("hello");
} /* Now how many lines of code is this? */
</source>
In this example we have:
* 4 Physical Lines of Code LOC (Is placing braces work to be estimated?)
* 2 Logical Line of Code lLOC (What about all the work writing non-statement lines?)
* 1 Comment Line (Tools must account for all code and comments regardless of comment placement.)
Even the "logical" and "physical" SLOC values can have a large number of varying definitions. Robert E. Park (while at the Software Engineering Institute) 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.
==Origins of SLOC==
At the time that people began using SLOC as a metric, the most commonly used languages, such as [[FORTRAN]] and [[Assembly language|assembler]], were line-oriented languages. These languages were developed at the time when [[punch cards]] were the main form of data entry for programming. One punch card usually represented one line of code. It was one discrete object that was easily counted. It was the visible output of the programmer so it made sense to managers to count lines of code as a measurement of a programmer's productivity. Today, the most commonly used computer languages allow a lot more leeway for formatting. One line of text no longer necessarily corresponds to one line of code.
==Usage of SLOC measures==
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 in terms of functionality than a developer who ends up creating more lines (and generally spending more effort). Good developers may merge multiple code modules into a single module, improving the system yet appearing to have negative productivity because they remove code. Also, especially skilled developers tend to be assigned the most difficult tasks, and thus may sometimes appear less "productive" than other developers on a task by this measure. Furthermore, inexperienced developers often resort to code duplication, which is highly discouraged as it is more bug-prone and costly to maintain, but it results in higher SLOC.
SLOC is particularly ineffective at comparing programs written in different languages unless adjustment factors are applied to normalize languages. Various [[computer language]]s balance brevity and clarity in different ways; as an extreme example, most [[assembly language]]s would require hundreds of lines of code to perform the same task as a few characters in [[APL programming language|APL]]. The following example shows a comparison of a [[Hello world program|"hello world" program]] written in [[C (programming language)|C]], and the same program written in [[COBOL]] - a language known for being particularly verbose.
{| class="wikitable" style="margin: 1em auto 1em auto"
! C || COBOL
|-
|
<source lang="c">
#include <stdio.h>
int main(void) {
printf("Hello World");
return 0;
}
</source>
||
<source lang="text">
000100 IDENTIFICATION DIVISION.
000200 PROGRAM-ID. HELLOWORLD.
000300
000400*
000500 ENVIRONMENT DIVISION.
000600 CONFIGURATION SECTION.
000700 SOURCE-COMPUTER. RM-COBOL.
000800 OBJECT-COMPUTER. RM-COBOL.
000900
001000 DATA DIVISION.
001100 FILE SECTION.
001200
100000 PROCEDURE DIVISION.
100100
100200 MAIN-LOGIC SECTION.
100300 BEGIN.
100400 DISPLAY " " LINE 1 POSITION 1 ERASE EOS.
100500 DISPLAY "Hello world!" LINE 15 POSITION 10.
100600 STOP RUN.
100700 MAIN-LOGIC-EXIT.
100800 EXIT.
</source>
|-
|Lines of code: 5<br />(excluding whitespace) || Lines of code: 17<br />(excluding whitespace)
|}
Another increasingly common problem in comparing SLOC metrics is the difference between auto-generated and hand-written code. Modern software tools often have the capability to auto-generate enormous amounts of code with a few clicks of a mouse. For instance, [[GUI builders]] automatically generate all the source code for a [[GUI object]] simply by dragging an icon onto a workspace. The work involved in creating this code cannot reasonably be compared to the work necessary to write a device driver, for instance. By the same token, a hand-coded custom GUI class could easily be more demanding than a simple device driver; hence the shortcoming of this metric.
There are several cost, schedule, and effort estimation models which use SLOC as an input parameter, including the widely-used Constructive Cost Model ([[COCOMO]]) series of models by [[Barry Boehm]] et al, [[PRICE Systems]] [[True S]] and Galorath's [[SEER-SEM]]. 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 point]]s 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 [[Andrew Tanenbaum]], the SLOC values for various operating systems in [[Microsoft]]'s [[Windows NT]] product line are as follows:
{| cellpadding="3" cellspacing="0" border="1" style="border-collapse: collapse" summary="Microsoft Windows NT SLOC Sizes"
|- bgcolor="#cccccc"
! Year || Operating System || SLOC (Million)
|-
| 1993 || Windows NT 3.1 || 4-5<ref name = "Knowing.NET">{{citation
|url=http://www.knowing.net/PermaLink,guid,c4bdc793-bbcf-4fff-8167-3eb1f4f4ef99.aspx
|title=How Many Lines of Code in Windows?
|publisher=Knowing.NET
|date=December 06, 2005
|accessdate=2007-10-18
}}<br>This in turn cites Vincent Maraia's ''The Build Master'' as the source of the information.</ref>
|-
| 1994 || Windows NT 3.5 || 7-8<ref name = "Knowing.NET"/>
|-
| 1996 || Windows NT 4.0 || 11-12<ref name = "Knowing.NET"/>
|-
| 2000 || Windows 2000 || more than 29<ref name = "Knowing.NET"/>
|-
| 2001 || Windows XP || 40<ref name = "Knowing.NET"/>
|-
| 2003 || Windows Server 2003 || 50<ref name = "Knowing.NET"/>
|}
[[David A. Wheeler]] studied the [[Red Hat]] distribution of the [[Linux|GNU/Linux operating system]], and reported that Red Hat Linux version 7.1 (released April 2001) contained over 30 million physical SLOC. He also extrapolated that, had it been developed by conventional proprietary means, it would have required about 8,000 person-years of development effort and would have cost over $1 billion (in year 2000 U.S. dollars).
A similar study was later made of [[Debian]] GNU/Linux version 2.2 (also known as "Potato"); this version of GNU/Linux was originally released in August 2000. This study found that Debian GNU/Linux 2.2 included over 55 million SLOC, and if developed in a conventional proprietary way would have required 14,005 person-years and cost $1.9 billion USD to develop. Later runs of the tools used report that the following release of Debian had 104 million SLOC, and [[as of 2005|as of year 2005]], the newest release is going to include over 213 million SLOC.
One can find figures of major operating systems (the various Windows versions have been presented in a table above)
{| cellpadding="3" cellspacing="0" border="1" style="border-collapse: collapse" summary="Operating Systems SLOC Sizes"
|- bgcolor="#cccccc"
! Operating System || SLOC (Million)
|-
| [[Red Hat Linux]] 6.2 || 17{{Fact|date=February 2007}}
|-
| Red Hat Linux 7.1 || 30{{Fact|date=February 2007}}
|-
| [[Debian]] 2.2 || 55-59<ref>{{cite web | author = González-Barahona, Jesús M., Miguel A. Ortuño Pérez, Pedro de las Heras Quirós, José Centeno González, and Vicente Matellán Olivera | title = Counting potatoes: the size of Debian 2.2 | url = http://people.debian.org/~jgb/debian-counting/counting-potatoes/ | work = debian.org | accessdate = 2003-08-12 }}</ref><ref name="debian-sloc">{{cite web | last = Robles | first = Gregorio | title = Debian Counting | url = http://libresoft.dat.escet.urjc.es/debian-counting/ | accessdate = 2007-02-16 }}</ref>
|-
| Debian 3.0 || 104<ref name="debian-sloc"/>
|-
| Debian 3.1 || 215<ref name="debian-sloc"/>
|-
| Debian 4.0 || 283<ref name="debian-sloc"/>
|-
| [[Opensolaris|OpenSolaris]] || 9.7
|-
| [[FreeBSD|FreeBSD]] || 8.8
|-
| [[Mac OS X]] 10.4 || 86<ref>{{cite web | last = Jobs | first = Steve | title = Live from WWDC 2006: Steve Jobs Keynote | url = http://www.engadget.com/2006/08/07/live-from-wwdc-2006-steve-jobs-keynote/ | year = [[2006]] | month = August | accessdate = 2007-02-16 | quote = 86 million lines of source code that was ported to run on an entirely new architecture with zero hiccups. | note = Possibly including the whole iLife suite, not just the operating system and usually bundled applications. }}</ref>
|-
| [[Linux (kernel)|Linux kernel]] 2.6.0 || 5.2
|}
In comparison, below are figures for various graphics applications.
{| cellpadding="3" cellspacing="0" border="1" style="border-collapse: collapse" summary="Graphics Programs"
|- bgcolor="#cccccc"
! Graphics Program || SLOC (Million)
|-
| [[OpenOffice.org]] || ~10{{Fact|date=February 2007}}
|-
| [[Blender (software)|Blender]] 2.42 || ~1{{Fact|date=February 2007}}
|-
| [[GIMP]] v2.3.8 || 0.65{{Fact|date=February 2007}}
|-
| [[Paint.NET]] 3.0 || 0.13{{Fact|date=February 2007}}
|}
==SLOC and relation to security faults==
{{quote|The central enemy of reliability is complexity.|Geer et al}}
A number of experts have claimed a relationship between the number of lines of code in a program and the number of bugs that it contains. This relationship is not simple, since the number of errors per line of code varies greatly according to the language used, the type of quality assurance processes, and level of testing, but it does appear to exist. More importantly, the number of bugs in a program has been directly related to the number of security faults that are likely to be found in the program.
This has had a number of important implications for system security and these can be seen reflected in operating system design. Firstly, more complex systems are likely to be more insecure simply due to the greater number of lines of code needed to develop them. For this reason, security focused systems such as [[OpenBSD]] grow much more slowly than other systems such as [[Microsoft Windows|Windows]] and [[Linux]]. A second idea, taken up in both OpenBSD and many Linux variants, is that separating code into different sections which run with different security environments (with or without special privileges, for example) ensures that the most security critical segments are small and carefully [[code audit|audited]].
{{Cleanup|date=July 2006}}
== Advantages ==
#Scope for Automation of Counting: Since Line of Code is a physical entity; manual counting effort can be easily eliminated by automating the counting process. Small utilities may be developed for counting the LOC in a program. However, a code counting utility developed for a specific language cannot be used for other languages due to the syntactical and structural differences among languages.
#An Intuitive Metric: Line of Code serves as an intuitive metric for measuring the size of software due to the fact that it can be seen and the effect of it can be visualized. Function Point is more of an objective metric which cannot be imagined as being a physical entity, it exists only in the logical space. This way, LOC comes in handy to express the size of software among programmers with low levels of experience.
== Disadvantages ==
{{quote|Measuring programming progress by lines of code is like measuring aircraft building progress by weight.|[[Bill Gates]]}}{{Fact|date=February 2007}}
#Lack of Accountability: Lines of code measure suffers from some fundamental problems. Some think it isn't useful to measure the productivity of a project using only results from the coding phase, which usually accounts for only 30% to 35% of the overall effort.
#Lack of Cohesion with Functionality: Though experiments have repeatedly confirmed that effort is highly correlated with LOC, functionality is less well correlated with LOC. That is, skilled developers may be able to develop the same functionality with far less code, so one program with less LOC may exhibit more functionality than another similar program. In particular, LOC is a poor productivity measure of individuals, since a developer can develop only a few lines and still be more productive than a developer creating more lines of code.
#Adverse Impact on Estimation: As a consequence of the fact presented under point (a), estimates done based on lines of code can adversely go wrong, in all possibility.
#Developer’s Experience: Implementation of a specific logic differs based on the level of experience of the developer. Hence, number of lines of code differs from person to person. An experienced developer may implement certain functionality in fewer lines of code than another developer of relatively less experience does, though they use the same language.
#Difference in Languages: Consider two applications that provide the same functionality (screens, reports, databases). One of the applications is written in C++ and the other application written in a language like COBOL. The number of function points would be exactly the same, but aspects of the application would be different. The lines of code needed to develop the application would certainly not be the same. As a consequence, the amount of effort required to develop the application would be different (hours per function point). Unlike Lines of Code, the number of Function Points will remain constant.
#Advent of [[Graphical_user_interface|GUI]] Tools: With the advent of GUI-based programming languages and tools such as [[Visual Basic]], programmers can write relatively little code and achieve high levels of functionality. For example, instead of writing a program to create a window and draw a button, a user with a GUI tool can use drag-and-drop and other mouse operations to place components on a workspace. Code that is automatically generated by a GUI tool is not usually taken into consideration when using LOC methods of measurement. This results in variation between languages; the same task that can be done in a single line of code (or no code at all) in one language may require several lines of code in another.
#Problems with Multiple Languages: In today’s software scenario, software is often developed in more than one language. Very often, a number of languages are employed depending on the complexity and requirements. Tracking and reporting of productivity and defect rates poses a serious problem in this case since defects cannot be attributed to a particular language subsequent to integration of the system. Function Point stands out to be the best measure of size in this case.
#Lack of Counting Standards: There is no standard definition of what a line of code is. Do comments count? Are data declarations included? What happens if a statement extends over several lines? – These are the questions that often arise. Though organizations like SEI and IEEE have published some guidelines in an attempt to standardize counting, it is difficult to put these into practice especially in the face of newer and newer languages being introduced every year.
#Psychology: A programmer whose productivity is being measured in lines of code, will be rewarded for generating more lines of code even though he could write the same functionality with fewer lines. The more management is focusing on lines of code, the more incentive the programmer has to expand his code with unneeded complexity. Since lines of code is proportional to the following cost of fixing bugs and maintaining the program in general, this is bad. Its an example of the business proverb: "What you measure is what you get."{{Fact|date=November 2007}}
== Related terms ==
KLOC: 1,000 lines of code
KDLOC: 1,000 delivered lines of code
KSLOC: 1,000 source lines of code
MLOC: 1,000,000 lines of code
GLOC: 1,000,000,000 lines of code
TLOC: 1,000,000,000,000 lines of code
{{howto}}
== Programs for counting lines of code==
There are many applications available for programmatically counting lines of code within source. Requirements for a source code metric tool should include the ability to process many source code languages and be operating system independent. Companies that use one tool for C on Windows and another tool for C on UNIX and a third tool for Java on Linux do not develop a common estimation basis for their CMMI metrics.
===Free/Open Source===
* The simplest source line counting command in UNIX variants is '''''wc'''''. For example, to count the number of lines in all <code>.cxx</code>, <code>.cpp</code>, <code>.h</code> and <code>.c</code> files in and below the current directory, one might use the [[POSIX]] commands [[find]] and [[wc (Unix)|wc]]:
<source lang="bash">
find . \( -name '*.[ch]' -o -name '*.cxx' -o -name '*.cpp' \) -exec wc -l {} \;
</source>
{| class="wikitable"
! Tool !! Platform / Interface !! Languages analyzed !! Analysis type !! License !! Details
|-
|[http://sourceforge.net/projects/cccc CCCC] || Cygwin, FreeBSD, Linux, Mac OS X, Microsoft Windows / [[Command line interface]] || C, C++, and Java || Physical only || [[GPL]] || Metrics supported include lines of code, McCabe's [[cyclomatic complexity]] and metrics proposed by Chidamber&Kemerer and Henry&Kafura.
|-
|[http://cloc.sourceforge.net/ cloc] || Perl || More than sixty programming and markup languages || Physical only || [[GPL]] || Counts physical lines of code, blank lines and comment lines. Comment definitions may be read from a file. Report summation features allow line counts to be aggregated by language and by project.
|-
|[http://sunset.usc.edu/research/CODECOUNT CodeCount] || Cygwin, FreeBSD, Linux, Mac OS X / Command line interface || Ada, Assembly, C and C++, COBOL, FORTRAN, Java, JOVIAL, Pascal, PL1, C#, JavaScript, MUL, Perl, SQL || Physical and logical || [[Shared source|Limited Public License]] || Requires significant manual steps to build and configure
|-
|[http://invisible-island.net c_count] || Cygwin, FreeBSD, Linux, Mac OS X / Command line interface || C, C++, Java || Physical and logical || [[MIT License]] ||
|-
|[http://sarovar.org/projects/kloc/ kloc] || Cygwin, FreeBSD, Linux, Mac OS X / Command line interface || C, C++, Java || Physical only || [[GPL]] || The line comment marker and block comment marker can be configured using a configuration file, allowing user to count effective lines of code and lines of comments for C, C++, Java, etc.
|-
|[http://metrics.sourceforge.net/ Metrics] || [[Eclipse (software)|Eclipse IDE]] / [[Graphical user interface]] || Java || Physical only || [[Common Public License|CPL]] ||
|-
|[http://labs.ohloh.net/ohcount/ Ohcount] || Linux, Mac OS X / Command line interface || More than fifty programming and markup languages || Physical only <!-- Ohloh once stated they count logical lines, as far as I remember, I found no definitive answer on this right now. --> || [[GPL]] v2 || Can analyze different languages within a single file and analyzes comment lines as well.
|-
|[http://www.dwheeler.com/sloccount SLOCCount] || Cygwin, FreeBSD, Linux, Mac OS X / Command line interface || More than two dozen programming languages || Physical only || [[GPL]] || Only reports lines of code
|}
===Freeware (Closed source)===
* [http://www.analogx.com/contents/download/program/kloc.htm K-LOC Calculator] is a free Windows tool for counting physical lines.
* [http://www.geocities.com/sivaram_subr/codeanalyzer/description.htm Code Analyzer] is a free Java tool for counting LoC, computing McCabe complexity etc. for various languages.
* [http://www.andreas-berl.de/linesofcodewichtel/en/index.html LinesOfCodeWichtel] is a free Java tool for counting lines of code in various languages.
* [http://www.locmetrics.com LocMetrics] is a free Windows tool for counting lines of C#, Java, or C++ code.
* [http://thecodecentral.com/2007/12/26/source-line-of-code-counter Source Line of Code Counter] A free .net based SLOC counter, supports regular expression matching, equipped with a directory browser.
* [http://www.campwoodsw.com/sourcemonitor.html Source Monitor] is a free Windows tool for counting lines of code and deriving metrics from C++, C, C#, Java, and other source code.
* Two [[Windows PowerShell]] ways to count SLOC in all .cxx, .cpp, .h, and .c files in and below the current directory:
Get-ChildItem -recurse -include *.cxx,*.cpp,*.h,*.c | Get-Content | Measure-Object -line
ls -r -i *.cxx,*.cpp,*.h,*.c | gc | measure-object -l
* The same simple counting of SLOC on a typical Unix-system:
find . -name "*.cxx" -or "*.cpp" -or -name "*.c" -or -name "*.h"
| xargs cat | wc -l
or
find . | egrep "\.(cxx|cpp|c|h)$"
|xargs cat | wc -l
===Commercial===
{{advert|date=June 2008}}
* [http://www.geronesoft.com/ Code Counter Pro], counts physical KLOCs and supports languages such as C, C++, C#, Java, Cobol, Delphi, VB, ASP, PHP and Fortran.
* [http://opsconsulting.com/codemetrics.htm CodeMetrics™] is an extensible code counting tool, which counts delivered source instructions (physical), logical lines, comment lines, comment lines with words, blank lines and total lines. The tool comes preloaded with 40+ language specifications and provides users with the capability to specify additional languages of interest. It also provides a basic COCOMO calculator.
*[http://www.ez-metrix.com EZ-Metrix] is a web-based source code counting utility that measures more than 75 different languages, and compares two file lists to quantify differences (i.e., new, modified, deleted, unmodified).
* [http://www.aivosto.com/project/project.html Project Analyer] is a static code analysis tool for VB.net, VB, VBA, & VBScript.
* [http://msquaredTechnologies.com Resource Standard Metrics] processes ANSI C, ANSI C++, C#, and Java 2.0+; it operates on Windows, UNIX, Linux and Mac OS X.
===Web-based===
* [[Ohloh]] extracts LOC and other software metrics of [[open source]] projects from publicly accessible [[Revision control|revision control repositories]]. It generates analyses and reports of development activity available as graphs and API-based web-services.
==Cultural references==
In the [[PBS]] documentary [[Triumph of the Nerds]], Microsoft executive [[Steve Ballmer]] criticized the use of counting lines of code:
<blockquote>
In IBM there's a religion in software that says you have to count K-LOCs, and a K-LOC is a thousand line of code. How big a project is it? Oh, it's sort of a 10K-LOC project. This is a 20K-LOCer. And this is 50K-LOCs. And IBM wanted to sort of make it the religion about how we got paid. How much money we made off [[OS/2]], how much they did. How many K-LOCs did you do? And we kept trying to convince them - hey, if we have - a developer's got a good idea and he can get something done in 4K-LOCs instead of 20K-LOCs, should we make less money? Because he's made something smaller and faster, less K-LOC. K-LOCs, K-LOCs, that's the methodology. Ugh! Anyway, that always makes my back just crinkle up at the thought of the whole thing.
</blockquote>
==References==
<references/>
==Additional reading==
* {{citation
|url=http://reports-archive.adm.cs.cmu.edu/anon/isri2005/CMU-ISRI-05-125.ps
|title=Forecasting Field Defect Rates Using a Combined Time-based and Metric–based Approach a Case Study of OpenBSD (CMU-ISRI-05-125)
|first1=Luo
|last1= Li
|first2=Jim
|last2= Herbsleb
|first3=Mary
|last3=Shaw
|publisher=Carnegie-Mellon University
|date=May 2005
}}
* {{cite journal
|url=ftp://dimacs.rutgers.edu/pub/dimacs/TechnicalReports/TechReports/2003/2003-13.ps.gz
| last = McGraw
| first = Gary
| title = From the Ground Up: The DIMACS Software Security Workshop
| journal = IEEE Security & Privacy
|date= March/April 2003
| volume = 1
| issue = 2
| pages = pp. 59-66
}}<!-- this is talking about a different type of metric -->
* {{cite journal
| author = Park, Robert E., ''et. al.''
| title = Software Size Measurement: A Framework for Counting Source Statements
| journal = Technical Report CMU/SEI-92-TR-20
| url = http://www.sei.cmu.edu/publications/documents/92.reports/92.tr.020.html
}}
==External links==
* [http://msquaredtechnologies.com/m2rsm/docs/rsm_metrics_narration.htm Definitions of Practical Source Lines of Code] Resource Standard Metrics (RSM) defines "effective lines of code" as a realistics code metric independent of programming style.
* [http://msquaredtechnologies.com/m2rsm/rsm_software_project_metrics.htm Effective Lines of Code eLOC Metrics for popular Open Source Software] Linux Kernel 2.6.17, Firefox, Apache HPPD, MySQL, PHP using RSM.
* {{cite web
| author = Wheeler, David A.
| title = SLOCCount
| url = http://www.dwheeler.com/sloccount
| accessdate = 2003-08-12
}}
* {{cite web
| author = Wheeler, David A.
| title = More than a Gigabuck: Estimating GNU/Linux's Size
| year = June 2001
| url = http://www.dwheeler.com/sloc
| accessdate = 2003-08-12
}}
* Tanenbaum, Andrew S. ''Modern Operating Systems'' (2nd ed.). Prentice Hall. ISBN 0-13-092641-8.
* {{ cite web
| url = http://www.computerworld.com.au/index.php/id;1942598204;pp;1
| title = Tanenbaum outlines his vision for a grandma-proof OS
| author = Howard Dahdah
| year = [[2007-01-24]]
| accessdate = 2007-01-29
}}
*[http://www.chris-lott.org/resources/cmetrics/ C. M. Lott: Metrics collection tools for C and C++ Source Code]
[[Category:Software metrics]]
[[de:Lines of Code]]
[[es:Líneas de código fuente]]
[[it:Source lines of code]]
[[no:SLOC]]
[[pl:KLOC]]
[[pt:Kloc]]