Line of code metrics. Software metrics and estimation
Download as PPTX, PDF0 likes3 views
Line of code metrics. Software metrics and estimation
![Year Operating system SLOC (million)
1993 Windows NT 3.1 4–5[3]
1994 Windows NT 3.5 7–8[3]
1996 Windows NT 4.0 11–12[3]
2000 Windows 2000 more than 29[3]
2001 Windows XP 45[4][5]
2003 Windows Server 2003 50[3]](https://image.slidesharecdn.com/metric5-250413063911-fd8f9cd1/85/Line-of-code-metrics-Software-metrics-and-estimation-7-320.jpg)
![• Advantages[edit]
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 software.
[15]
As such, it is arguable that more LOC data is available than any other size measure.](https://image.slidesharecdn.com/metric5-250413063911-fd8f9cd1/85/Line-of-code-metrics-Software-metrics-and-estimation-8-320.jpg)
![Disadvantages
1.Lack of accountability: lines-of-code measure suffers from some fundamental problems.
Some[who?]
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]
2.Lack of cohesion with functionality: though experiments[by 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.](https://image.slidesharecdn.com/metric5-250413063911-fd8f9cd1/85/Line-of-code-metrics-Software-metrics-and-estimation-9-320.jpg)
Line of code metrics. Software metrics and estimation
- 1. Line of code metrics Faiz ul haque Zeya Senior associate professor BUKC
- 2. • physical SLOC (LOC) • logical SLOC (LLOC).
- 3. • physical SLOC is a count of lines in the text of the program's source code excluding comment lines.
- 4. • Now how many lines of code is this? */ • for (i = 0; i < 100; i++) • { • printf("hello"); • } • 4 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.
- 5. • Logical SLOC attempts to measure the number of executable "statements",
- 6. for (i = 0; i < 100; i++) printf("hello"); /* How many lines of code is this? */ • 1 physical line of code (LOC), • 2 logical lines of code (LLOC) (for statement and printf statement), • 1 comment line.
- 7. Year Operating system SLOC (million) 1993 Windows NT 3.1 4–5[3] 1994 Windows NT 3.5 7–8[3] 1996 Windows NT 4.0 11–12[3] 2000 Windows 2000 more than 29[3] 2001 Windows XP 45[4][5] 2003 Windows Server 2003 50[3]
- 8. • Advantages[edit] 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 software. [15] As such, it is arguable that more LOC data is available than any other size measure.
- 9. Disadvantages 1.Lack of accountability: lines-of-code measure suffers from some fundamental problems. Some[who?] 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] 2.Lack of cohesion with functionality: though experiments[by 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.
- 10. 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.
- 11. • Counting Source Lines of Code (SLOC) (dwheeler.com) • C. M. Lott: Metrics tools for C/C++ (archive.org) • RSM Metrics Narration (archive.org)