Editing Source lines of code (section)

=== Disadvantages ===
# Lack of accountability: lines-of-code measure suffers from some fundamental problems. Some {{Who|date=April 2010}} think that 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.{{Citation needed|date=May 2010}}
# Lack of cohesion with functionality: though experiments {{By whom|date=April 2010}} 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.
# 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.
# 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 (classic)|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 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 their 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:
<blockquote>
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.
</blockquote>
According to the [[Computer History Museum]] Apple Developer [[Bill Atkinson]] in 1982 found problems with this practice:
<blockquote>
When the Lisa team was pushing to finalize their software in 1982, project managers started requiring programmers to submit weekly forms reporting on the number of lines of code they had written. Bill Atkinson thought that was silly. For the week in which he had rewritten QuickDraw’s region calculation routines to be six times faster and 2000 lines shorter, he put “-2000″ on the form. After a few more weeks the managers stopped asking him to fill out the form, and he gladly complied.<ref>{{Cite web|date=2010-07-18|title=MacPaint and QuickDraw Source Code|url=https://computerhistory.org/blog/macpaint-and-quickdraw-source-code/|access-date=2021-04-15|website=CHM|language=en}}</ref><ref>{{Cite web|title=Folklore.org: -2000 Lines Of Code|url=https://www.folklore.org/StoryView.py?story=Negative_2000_Lines_Of_Code.txt|access-date=2021-04-15|website=www.folklore.org}}</ref>
</blockquote>