Source Line Statistics

Source line statistics have the advantage that they are easily understood and relatively easy to collect, especially with an automated source code analysis tool like VB Law.

Types of Source Line Statistics

Source line statistics traditionally include the following:

• Code Line Count
• Comment Line Count
• Blank Line Count
• Code Comment Ratio

Source Line Statistics As A Measure of Code Quality

Pure line counts on their own cannot be used to provide any real measure of the quality of the code being analysed, however, it is not unreasonable to draw the following conclusions for each of the following:

High Code Line Count

The greater the number of source lines in your application, the greater the maintenance effort and costs. There is also a stronger probability of a greater number of defects to be identified and corrected.

High Code Line Counts At The Procedure Level

A procedure that has a very large number of code lines is often indicative of poor code design and structure. It is also likely to be difficult to understand and therefore any changes to it are likely to be high risk.

Low Code Comment Ratio

A low code comment ratio (comment lines/(code lines + comment lines)) indicates that the code is poorly documented and depending upon the complexity of the code may be difficult and time consuming for any developer unfamiliar with it to determine how it works. This means that changes to the code are likely to be higher risk than changes to code with higher code comment ratios.

Low Blank Line Count, High Code Line Count

Although there may be nothing wrong with the source code, a low blank line count means that it is very dense and therefore probably difficult to read. Code that is difficult to read is harder to understand and thus code changes are likely to be more risky. Correct use of white space, and particularly blank lines, can greatly improve source code readability.

Source Line Statistics As A Project Management Tool

If source line statistics are obtained at regular intervals throughout a project's life cycle then code growth can be measured and, if compared to the expected growth, it can identify projects that may be experiencing problems.

Code Growth Studies

A number of studies of code growth have shown that it follows a particular profile as demonstrated by the following graph based on a study by NASA's Software Engineering Laboratory of 20 of it's own projects following a waterfall life cycle. (For more information see the NASA Software Measurement Guidebook.)

It is probably not safe to assume that all projects will follow this code growth profile exactly as it depends to a certain extent on the following factors:

Development methodology adopted - an iterative methodology for example will tend to show a stepped growth profile.

Developer resource availability - if extra resource is added to a project you could reasonably expect code growth to increase significantly.

Availability of reusable code - code growth will increase significantly if reusable code from another source is added to a project.

Notwithstanding the above, if an organisation is able to determine the expected code growth for a typical project then measuring it and comparing to the expectation can be a valuable indicator of the project progress.