Wed . 19 Aug 2019
TR | RU | UK | KK | BE |

Source lines of code

source lines of code, source lines of code per hour
Source lines of code SLOC, also known as lines of code LOC, is a software metric used to measure the size of a computer 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 maintainability once the software is produced


  • 1 Measurement methods
  • 2 Origins
  • 3 Usage of SLOC measures
    • 31 Example
  • 4 Utility
    • 41 Advantages
    • 42 Disadvantages
  • 5 Related terms
  • 6 See also
  • 7 Notes
  • 8 References
  • 9 Further reading
  • 10 External links

Measurement methodsedit

Many useful comparisons involve only the order of magnitude of lines of code in a project 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 LOC and logical SLOC LLOC 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 excluding comment lines1

Logical SLOC attempts to measure the number of executable "statements", but their specific definitions are tied to specific computer languages one simple logical SLOC measure for C-like programming 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 However, 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:

for i = 0; i < 100; i++ printf"hello"; / How many lines of code is this /

In this example we have:

  • 1 Physical Line of Code LOC
  • 2 Logical Lines of Code LLOC for statement and printf statement
  • 1 comment line

Depending on the programmer and coding standards, the above "line of code" could be written on many separate lines:

/ Now how many lines of code is this / for i = 0; i < 100; i++

In this example we have:

  • 5 Physical Lines of Code LOC: is placing braces work to be estimated
  • 2 Logical Lines 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 and others 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


At the time that people began using SLOC as a metric, the most commonly used languages, such as FORTRAN and assembler, were line-oriented languages These languages were developed at the time when punched cards were the main form of data entry for programming One punched 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, even referring to such as "card images" Today, the most commonly used computer languages allow a lot more leeway for formatting Text lines are no longer limited to 80 or 96 columns, and one line of text no longer necessarily corresponds to one line of code

Usage of SLOC measuresedit

SLOC measures are somewhat controversial, particularly in the way that they are sometimes misused Experiments have repeatedly confirmed that effort is highly correlated with SLOCcitation needed, 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 fewer 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 languages balance brevity and clarity in different ways; as an extreme example, most assembly languages would require hundreds of lines of code to perform the same task as a few characters in APL The following example shows a comparison of a "hello world" program written in C, and the same program written in COBOL - a language known for being particularly verbose

Lines of code: 4
excluding whitespace
Lines of code: 17
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, graphical user interface builders automatically generate all the source code for a graphical control elements 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 Manywho 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 Vincent Maraia,2 the SLOC values for various operating systems in Microsoft's Windows NT product line are as follows:

Year Operating System SLOC Million
1993 Windows NT 31 4–52
1994 Windows NT 35 7–82
1996 Windows NT 40 11–122
2000 Windows 2000 more than 292
2001 Windows XP 4534
2003 Windows Server 2003 502

David A Wheeler studied the Red Hat distribution of the Linux operating system, and reported that Red Hat Linux version 715 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 US dollars

A similar study was later made of Debian GNU/Linux version 22 also known as "Potato"; this operating system was originally released in August 2000 This study found that Debian GNU/Linux 22 included over 55 million SLOC, and if developed in a conventional proprietary way would have required 14,005 person-years and cost $19 billion USD to develop Later runs of the tools used report that the following release of Debian had 104 million SLOC, and as of year 2005update, 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

Year Operating System SLOC Million
2000 Debian 22 55–5967
2002 Debian 30 1047
2005 Debian 31 2157
2007 Debian 40 2837
2009 Debian 50 3247
2012 Debian 70 4198
2009 OpenSolaris 97
FreeBSD 88
2005 Mac OS X 104 869n 1
2001 Linux kernel 242 245
2003 Linux kernel 260 52
2009 Linux kernel 2629 110
2009 Linux kernel 2632 12610
2010 Linux kernel 2635 13511
2012 Linux kernel 36 15912
2015-06-30 Linux kernel pre-42 20213



  1. 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 logical code counting utility developed for a specific language cannot be used for other languages due to the syntactical and structural differences among languages Physical LOC counters, however, have been produced which count dozens of languages
  2. An Intuitive Metric: Line of Code serves as an intuitive metric for measuring the size of software because it can be seen and the effect of it can be visualized Function points are said to be 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
  3. Ubiquitous Measure: LOC measures have been around since the earliest days of softwarecitation needed As such, it is arguable that more LOC data is available than any other size measure


  1. Lack of Accountability: Lines of code measure suffers from some fundamental problems Somewho 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 effortcitation needed
  2. Lack of Cohesion with Functionality: Though experimentsby whom have repeatedly confirmed that while 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, because a developer who develops only a few lines may still be more productive than a developer creating more lines of code - even more: some good refactoring like "extract method" to get rid of redundant code and keep it clean will mostly reduce the lines of code
  3. Adverse Impact on Estimation: Because of the fact presented under point #1, estimates based on lines of code can adversely go wrong, in all possibility
  4. 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
  5. 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
  6. Advent of 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
  7. 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
  8. 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
  9. Psychology: A programmer whose productivity is being measured in lines of code will have an incentive to write unnecessarily verbose code The more management is focusing on lines of code, the more incentive the programmer has to expand his code with unneeded complexity This is undesirable since increased complexity can lead to increased cost of maintenance and increased effort required for bug fixing

In the PBS documentary Triumph of the Nerds, Microsoft executive Steve Ballmer criticized the use of counting lines of code:

In IBM there's a religion in software that says you have to count K-LOCs, and a K-LOC is a thousand lines 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

Related termsedit

  • KLOC /ˈkeɪlɒk/ KAY-lok: 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

See alsoedit

  • Software development effort estimation
  • Estimation project management
  • Comparison of development estimation software


  1. ^ Possibly including the whole iLife suite, not just the operating system and usually bundled applications


  1. ^ Vu Nguyen; Sophia Deeds-Rubin; Thomas Tan; Barry Boehm 2007, A SLOC Counting Standard PDF, Center for Systems and Software Engineering , University of Southern California 
  2. ^ a b c d e f "How Many Lines of Code in Windows" Scholar search KnowingNET December 6, 2005 Retrieved 2010-08-30 
    This in turn cites Vincent Maraia's The Build Master as the source of the information
  3. ^ "How Many Lines of Code in Windows XP" Microsoft January 11, 2011 
  4. ^ "A history of Windows" Microsoft 
  5. ^ a b David A Wheeler 2001-06-30 "More Than a Gigabuck: Estimating GNU/Linux's Size" 
  6. ^ 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 "Counting potatoes: the size of Debian 22" debianorg Archived from the original on 2008-05-03 Retrieved 2003-08-12  CS1 maint: Multiple names: authors list link
  7. ^ a b c d e Robles, Gregorio "Debian Counting" Retrieved 2007-02-16 
  8. ^ Debian 70 was released in May 2013 The number is an estimate published on 2012-02-13, using the code base which would become Debian 70, using the same software method as for the data published by David A Wheeler James Bromberger "Debian Wheezy: US$19 Billion Your price… FREE!" Archived from the original on 2014-02-23 Retrieved 2014-02-07 
  9. ^ Jobs, Steve August 2006 "Live from WWDC 2006: Steve Jobs Keynote" Retrieved 2007-02-16 86 million lines of source code that was ported to run on an entirely new architecture with zero hiccups 
  10. ^ "What's new in Linux 2632" Archived from the original on 2013-12-19 Retrieved 2009-12-24  CS1 maint: BOT: original-url status unknown link
  11. ^ Greg Kroah-Hartman; Jonathan Corbet; Amanda McPherson April 2012 "Linux Kernel Development: How Fast it is Going, Who is Doing It, What They are Doing, and Who is Sponsoring It" The Linux Foundation Retrieved 2012-04-10 
  12. ^ "Summary, Outlook, Statistics - The H Open: News and Features" Archived from the original on 2013-12-19 Retrieved 2012-10-08  CS1 maint: BOT: original-url status unknown link Retrieved on 2014-05-13
  13. ^ http://heisede/-2730780

Further readingedit

  • Li, Luo; Herbsleb, Jim; Shaw, Mary May 2005 Forecasting Field Defect Rates Using a Combined Time-based and Metric–based Approach a Case Study of OpenBSD CMU-ISRI-05-125 Carnegie-Mellon University 
  • McGraw, Gary March–April 2003 "From the Ground Up: The DIMACS Software Security Workshop" IEEE Security & Privacy 1 2: 59–66 doi:101109/MSECP20031193213 
  • Park, Robert E; et al "Software Size Measurement: A Framework for Counting Source Statements" Technical Report CMU/SEI-92-TR-20 

External linksedit

  • 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
  • Effective Lines of Code eLOC Metrics for popular Open Source Software Linux Kernel 2617, Firefox, Apache HTTPD, MySQL, PHP using RSM
  • Wheeler, David A "SLOCCount" Retrieved 2003-08-12 
  • Wheeler, David A June 2001 "Counting Source Lines of Code SLOC" Retrieved 2003-08-12 
  • Tanenbaum, Andrew S Modern Operating Systems 2nd ed Prentice Hall ISBN 0-13-092641-8
  • Howard Dahdah 2007-01-24 "Tanenbaum outlines his vision for a grandma-proof OS" Retrieved 2007-01-29 
  • C M Lott: Metrics collection tools for C and C++ Source Code
  • Folkloreorg: Macintosh Stories: -2000 Lines Of Code

effective source lines of code, source lines of code, source lines of code per hour, source lines of code sloc, source lines of codes

Source lines of code Information about

Source lines of code

  • user icon

    Source lines of code beatiful post thanks!


Source lines of code
Source lines of code
Source lines of code viewing the topic.
Source lines of code what, Source lines of code who, Source lines of code explanation

There are excerpts from wikipedia on this article and video

Random Posts

Amorphous metal

Amorphous metal

An amorphous metal also known as metallic glass or glassy metal is a solid metallic material, usuall...
Arthur Lake (bishop)

Arthur Lake (bishop)

Arthur Lake September 1569 – 4 May 1626 was Bishop of Bath and Wells and a translator of the King Ja...
John Hawkins (author)

John Hawkins (author)

Sir John Hawkins 29 March 1719 – 21 May 1789 was an English author and friend of Dr Samuel Johnson a...
McDonnell Douglas MD-12

McDonnell Douglas MD-12

The McDonnell Douglas MD-12 was an aircraft design study undertaken by the McDonnell Douglas company...

Random Posts (



Wargame (from the English. "Wargame" - Russian. "War game") - a kind of strategi
Nikolskoe (Gorshechensky district)

Nikolskoe (Gorshechensky district)

Nikolskoye - a village in the Gorshechensky district of the Kursk region of Russia The administrativ
Rosario, Amed

Rosario, Amed

Herman Amed Valdez Rosario Isp German Amed Valdez Rosario, November 20, 1995, Santo Domingo - Domini
Apartment zero

Apartment zero

Thriller Drama Director Martin Donovan Producer Martin Donovan David Kepp Screenwriter Marti