Source Lines of Code (SLOC)

Which mode should I choose: physical or logical?

Both methods have various pros and cons, as described in the following paragraphs. It is up to you as the developer or project manager to determine which method best allows you to compare files and projects. If you are plugging KinetiCount results into a cost model, use the method and options which most closely reflect the model's input requirements.

Physical Mode:

Lines are counted as they appear visually in the source code file. A line may be classified as any one of the following:

• Physical lines (contains only code)
• Comments
• On their own lines
• On lines with source code (mixed)
• Banners and non-blank spacers
• Blank (empty) comments
• Blank lines

Any line containing at least one character that is non-whitespace (and not part of a comment) is considered to contain code.

This method is very sensitive to the coding style used in the source code files. For example, some programmers may prefer to fit multiple statements on a single line:

While the call to performSomeTask() is technically its own statement, it is considered a part of the same statement as the logical comparison here, because it appears on the same physical line. The following code segments, which accomplish exactly the same thing, would be counted as two physical lines and four physical lines, respectively:

Pros:

Because lines are counted as they appear to human eyes, a line count in one language may be compared to a line count in another. However, this method will be most accurate and useful when comparing code written in a similar style and language.

Cons:

In many cases, the coding style used in different files or projects may vary greatly (for example, a large project written by several different individual developers, especially in the case of open-source projects) this method may produce widely varying line counts.

---

Logical Mode:

There is no official definition of "logical" SLOC, but KinetiCount uses one of two primary metrics, depending on your preference:

1. Using terminating semicolons (C/C++ files) or line feeds (resource scripts)
• Terminating semicolons
• Comments
• On their own lines
• On lines with source code (mixed)
• Banners and non-blank spacers
• Blank (empty) comments
• Blank lines
2. Using the Software Engineering Institute's SLOC statement type checklist:

• Executable
• Nonexecutable
• Declarations
• Compiler Directives
• Comments
• On their own lines
• On lines with source code (mixed)
• Banners and non-blank spacers
• Blank (empty) comments
• Blank lines

Additionally, when considering executable statements in C/C++, you may choose to treat functions with fully capitalized names as macros. If so, you may choose whether to consider them as single executable statements just like function calls, or not at all.

Using a logical count mode is less sensitive to coding style, because the count more closely reflects the number of actions which occur. Take the following examples:

If semicolons are used to count lines in the above examples, both contain 3 SLOC. If executable statements are used, we have 2 executable lines (a function call and an assignment, which is technically a call to a constructor in this case) and 3 non-executable lines (an int declaration, a bool declaration, and a function declaration).

A more detailed example:

Depending on the count mode, the above code contains the following:

• Physical:
  • 11 statement lines
  • 2 comment-only lines
  • 2 banner comment lines
  • 3 blank lines
• Logical (Terminating Semicolons):
  • 5 terminating semicolons
  • 2 comment-only lines
  • 2 banner comment lines
  • 3 blank lines
• Logical (Executable Statements):
  • 15 executable statements
  • 3 declarations
  • 1 compiler directive
  • 2 comment-only lines
  • 2 banner comment lines
  • 3 blank lines

Note that the C++ scope resolution operator (::) is not considered an executable statement, because the full type can always be resolved at compile-time.

Pros:

Many cost estimation models require executable statements as input instead of physical lines. Because a count of executable statements is less sensitive to individual coding style, and may be more useful when comparing source code that has been (or will be) written by different developers.

For example, argument lists, string literal concatenation, and similar constructs may be spread among several lines, depending on the style of the programmer(s). Using logical mode, these are all treated the same, regardless of how many physical lines they may occupy.

Cons:

Parsing executable statements is a more complex operation, and increases analysis time. Additionally, function calls are considered single executions, no matter what actual code the function body may contain. Of course, this is a non-issue if the function body is also included somewhere in one of the project's files.

If you choose to count C/C++ macros as logical lines of code, remember that these calls may also produce several more executable lines of code when compiled. KinetiCount is not a compiler, and therefore does not care about implementation details. When using the same or similar functions/classes/libraries throughout projects, however, the effect on magnitude is likely negligible.