Source Lines of Code - Revision history

User at 21:06, 6 December 2022

2022-12-06T21:06:12Z

User: The LinkTitles extension automatically added links to existing pages (https://github.com/bovender/LinkTitles).

2021-02-06T18:27:54Z

The LinkTitles extension automatically added links to existing pages (https://github.com/bovender/LinkTitles).

User at 20:03, 16 January 2020

2020-01-16T20:03:12Z

User at 20:02, 16 January 2020

2020-01-16T20:02:37Z

User: Created page with "'''Content Coming Soon'''"

2019-01-07T07:12:17Z

Created page with "'''Content Coming Soon'''"

New page

'''Content Coming Soon'''

← Older revision		Revision as of 21:06, 6 December 2022
Line 1:		Line 1:
−	'''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\|~~computer program]] by counting the number of lines in the text of the program's [[Source Code\|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\|software]] is produced.<ref>Definition - What Does Source lines of code (SLOC) Mean? [https://en.wikipedia.org/wiki/Source_lines_of_code Wikipedia]</ref>	+	'''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\|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\|software]] is produced.<ref>Definition - What Does Source lines of code (SLOC) Mean? [https://en.wikipedia.org/wiki/Source_lines_of_code Wikipedia]</ref>

	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 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. Counting SLOC as productivity measure has its caveats, 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 counting exhibits further accuracy issues 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.		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 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. Counting SLOC as productivity measure has its caveats, 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 counting exhibits further accuracy issues 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.

@@ Line 1: / Line 1: @@
-'''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|computer program]] by counting the number of lines in the text of the program's [[Source Code|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|software]] is produced.<ref>Definition - What Does Source lines of code (SLOC) Mean? [https://en.wikipedia.org/wiki/Source_lines_of_code Wikipedia]</ref>
+'''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|computer program]] by counting the number of lines in the text of the program's [[Source Code|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|software]] is produced.<ref>Definition - What Does Source lines of code (SLOC) Mean? [https://en.wikipedia.org/wiki/Source_lines_of_code Wikipedia]</ref>
-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 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. Counting SLOC as productivity measure has its caveats, 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 counting exhibits further accuracy issues 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.
+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 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. Counting SLOC as productivity measure has its caveats, 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 counting exhibits further accuracy issues 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.
 '''Physical and Logical SLOC<ref>Physical and Logical SLOC [https://www.viva64.com/en/t/0086/ PVS-Studio]</ref>'''
 There are two major types of SLOC measures: physical SLOC and logical SLOC. Specific definitions of these terms vary depending on particular circumstances. The most common definition of physical SLOC is a count of lines in the text of the program's source code including comment lines and, sometimes, blank lines. Logical SLOC attempts to measure the number of executable expressions (such as operators, functions, etc.), but their specific definitions are tied to specific computer languages. Therefore, each approach has its own strong and weak points: physical SLOC is easier to measure, but it is very sensitive to coding style conventions and code formatting, while logical SLOC is less sensitive to these factors yet not so easy to measure.

← Older revision		Revision as of 20:03, 16 January 2020
Line 4:		Line 4:


−	Physical and Logical SLOC<ref>Physical and Logical SLOC [https://www.viva64.com/en/t/0086/ PVS-Studio]</ref>	+	'''Physical and Logical SLOC<ref>Physical and Logical SLOC [https://www.viva64.com/en/t/0086/ PVS-Studio]</ref>'''
	There are two major types of SLOC measures: physical SLOC and logical SLOC. Specific definitions of these terms vary depending on particular circumstances. The most common definition of physical SLOC is a count of lines in the text of the program's source code including comment lines and, sometimes, blank lines. Logical SLOC attempts to measure the number of executable expressions (such as operators, functions, etc.), but their specific definitions are tied to specific computer languages. Therefore, each approach has its own strong and weak points: physical SLOC is easier to measure, but it is very sensitive to coding style conventions and code formatting, while logical SLOC is less sensitive to these factors yet not so easy to measure.		There are two major types of SLOC measures: physical SLOC and logical SLOC. Specific definitions of these terms vary depending on particular circumstances. The most common definition of physical SLOC is a count of lines in the text of the program's source code including comment lines and, sometimes, blank lines. Logical SLOC attempts to measure the number of executable expressions (such as operators, functions, etc.), but their specific definitions are tied to specific computer languages. Therefore, each approach has its own strong and weak points: physical SLOC is easier to measure, but it is very sensitive to coding style conventions and code formatting, while logical SLOC is less sensitive to these factors yet not so easy to measure.

← Older revision		Revision as of 20:02, 16 January 2020
Line 1:		Line 1:
−	'''~~Content Coming Soon~~'''	+	'''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\|computer program]] by counting the number of lines in the text of the program's [[Source Code\|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\|software]] is produced.<ref>Definition - What Does Source lines of code (SLOC) Mean? [https://en.wikipedia.org/wiki/Source_lines_of_code Wikipedia]</ref>
		+
		+	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 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. Counting SLOC as productivity measure has its caveats, 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 counting exhibits further accuracy issues 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.
		+
		+
		+	Physical and Logical SLOC<ref>Physical and Logical SLOC [https://www.viva64.com/en/t/0086/ PVS-Studio]</ref>
		+	There are two major types of SLOC measures: physical SLOC and logical SLOC. Specific definitions of these terms vary depending on particular circumstances. The most common definition of physical SLOC is a count of lines in the text of the program's source code including comment lines and, sometimes, blank lines. Logical SLOC attempts to measure the number of executable expressions (such as operators, functions, etc.), but their specific definitions are tied to specific computer languages. Therefore, each approach has its own strong and weak points: physical SLOC is easier to measure, but it is very sensitive to coding style conventions and code formatting, while logical SLOC is less sensitive to these factors yet not so easy to measure.