1. Source Lines of Code (SLOC)
Counting lines of
code is probably the most simple method. It mostly indicates the scale
of the software and gives an input for project growth and planning. For
example, if we get SLOC count once a month, we may sketch a graph of
project growth. Of course this is not reliable due to refactoring and
design phases but may give a viewpoint.
SLOC may be counted
as Source Logical Line of Code (SLLOC) for better info. Logical code
lines does not include empty lines, one char brackets and comment lines.
You can easily calculate SLLOC using tools like Metrics.
Line of code should
not be used for evaluating developer performance. This may cause
duplicate, unmaintainable and unprofessional code.
2. Bugs per code_section/module/time_period
Bug tracking is
essential for better testing and faster maintainability. If bugs are
tracked, bugs per code section, module or specific time period (day,
week, month etc.) may be calculated easily by reporting tools (e.g. Mantis). If this value is obtained, bug causes may be noticed and intervened early.
Bug count may be
used as one of the inputs of evaluating developer performance, but
attention must be paid. If it is most important evaluation method,
software developers and testers may become enemies. In a productive
company, all employees must be coherent with each other.
evaluation, bugs may be classified as low, medium, high etc. for
weighting, because their importance and resolving costs are not the
3. Code Coverage
Code coverage states the degree to which the source code of a program has been tested. Automaticity of code coverage calculation is a plus. There are so many tools which perform that operation (e.g. Cobertura).
4. Design/Development Constraints
There are so many design constraints and principles for software development. Some of them are:
does not represent the whole quality of unit tests, but may give some
info about test coverage. It may be used as a software metric together
with a few other test metrics. Also unit test codes, integration test
scenarios and results should be reviewed frequently.
- Class/method length,
- Number of methods/attributes in a class,
- Method/constructor parameter counts,
- Magical number, string usage in code files,
- Comment lines percentage etc.
These are important
for code maintainability and readability. Development teams may choose a
few (or all) of those metrics and follow them with automized tools
(like maven pmd plugin). This will raise the quality of produced software.
5. Cyclomatic Complexity
cyclomatic complexity from other design/development constraints because
its concept is a bit different. Cyclomatic complexity is about the
detailed implementation and code execution. It also may be calculated
automatically with tools like pmd.
It is calculated as "the count of the number of linearly independent paths through a source code section". For example, if there are a path diagram of a source code section as below:
Cyclomatic Complexity = E(edges) - N(nodes) + 2P (exit nodes)
So, Cyc.Cmp. = 8 - 7 + 2*1 = 3
You can also see
that there are 3 different paths from leftmost node to rightmost node.
This value can be calculated especially for methods, using the whole
method source as the execution path. Some upper limit numbers (6, 8 or
10 etc.) may be defined according to the project type.
Only one metric
does not detect the quality of your whole project or solve everything.
If you use more metrics, you will have more viewpoints about the quality
of your project.