There are several problems with using LOC as a unit of measure for
software. Imagine two
applications that provide the same exact
functionality (screens, reports,
databases). One of the
applications is
written in C++ and the other application written a language like
Clarion (a very
visual language). 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 not be
the
same. The amount of effort required to develop the application would
be different (hours per
function point). We are able to compare the
productivity of the languages.
Unlike Lines of
Code, the number of
function points will remain constant (should remain
constant).
With this in mind:
- The number of lines of code delivered is dependent upon the
skill level of the
programmer. In fact, the higher skill level of
the programmer the fewer lines
of code
they will develop to perform
the same function.
- Higher-level languages such as Delphi, Progress 4GL, Forte,
Dynasty, VB, Java Script,
or other visual languages require far
fewer lines of code than
Assembler, COBOL, or C
to perform the same
functionality. That is, there is an inverse
relationship between
level
of language and work output (when work output is LOC).
- The actual number of LOC is not known until the project is
almost completed.
Therefore, LOC cannot be used to estimate the
effort or schedule of a
project. Function
Points can be derived from
requirements and analysis documents that are
available early
in a
project life cycle.
- There is no agreed upon method to count lines of code. The
statement and type of
statements used in Visual C++, Assembler,
COBOL, SQL are completely
different. It is
common for applications to
have a combination of different languages
being utilized.