Counting the statements
To measure the size of an application and to evaluate the work done, count the statements, not the lines.
Did you ever need to count the lines in a program? You probably noticed that simple "source lines of code" (LOC, sLOC) metrics have their problems. The more comments you add, the more blanks you put in, the more statements you split over several lines, the higher line counts you get - but no more functionality.
It doesn't stop here. You can actually write a big app that doesn't have any functionality at all. Consider a skeleton app with only variable definitions, empty methods and other declarations. If you count the lines, the app looks big, even when there are no executable statements in it.
As you can see, simple line counts are subject to measurement error. Statement counts are a more objective way to estimate the size of an app. You can't bloat statement counts by simply hitting the Enter key or hiding meaningless 10-line comment blocks in the source.
Statement counts and statement types
What's a statement? In many languages (such as C, C++, C# or Java), a statement is something that ends with a semicolon (;). In Basic, inlucing VB, there is usually one statement on each line, but you can put several statements on a line with the colon (:). The exact definition varies by language.
Depending on your objectives, you can count all the statements or classify them into several groups. Our classification follows below.
Statement counts are informative as such. If you added 1000 executable statements last month, you probably worked hard on your code (unless you copy & pasted some routines to bloat your app). Most probably, a program of 10,000 statements has less functionality than a 20,000 statement system. You can use statement counts to evaluate the work done and to compare projects or teams.
The usefulness of statement counts doesn't stop at the raw numbers. From the raw statement counts you can calculate additional metrics. These metrics can tell you about the quality of the source code.
Executability measures the amount of executable statements. It equals the number of executable statements divided by the number of all statements.
XQT = STMTx / STMT
A project with a low XQT contains relatively many declarative statements such as class declarations, user-defined types, variables, procedures, events, enumerations and constants. An extremely low XQT could indicate missing implementation, where only the declarative code is in place and the executable code is missing. Alternatively, the program could be bloated with too many declarations that are of little use.
When XQT is high, the amount of declarations is relatively low and the amount of executable code is thus high. A high XQT could be an indication of a bad design. The addition of temporary variables, the use of constants and shorter procedures could add legibility to the application.
CTRL Control density
Control density measures the amount of control statements. It equals the number of control statements divided by the number of all executable statements.
CTRL = STMTc / STMTx
A low CTRL indicates a program with relatively few jumps, loops, conditionals or error handling relative to other executable code. The control flow is relatively straight and clear, and the continuous blocks of code are long. A high CTRL indicates a high amount of jumps, loops, conditionals and error handling. The amount of actual data processing may be low as most of the code is devoted to logic and jumps. The code may be inherently complex, or it may be badly designed.
Software to count VB metrics
Manually counting the statements is possible, but maybe a bit tiring. If your code is VB, VB.NET or VBA, you can use Project Analyzer to count the statements and lines. Project Metrics, a feature of Project Analyzer, counts a large number of metrics and stores them for you to keep project history records and compare systems to each other.
Behind the below links you can read more information on Project Metrics and how it counts the lines and statements.