Cagdas Basaraner is a software engineer graduated from Hacettepe University Computer Engineering department and Information Systems master program (Turkey). He has 5 years of professional experience, and is working on information systems with JEE web technologies. He is also a former developer of information systems with Microsoft .NET technologies and Command & Control (C4I) systems with Java technologies. Cagdas is a DZone MVB and is not an employee of DZone and has posted 23 posts at DZone. You can read more from them at their website. View Full User Profile

5 Common Automized Software Quality Metrics (with Pros & Cons)

10.09.2012
| 7333 views |
  • submit to reddit
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.


For better evaluation, bugs may be classified as low, medium, high etc. for weighting, because their importance and resolving costs are not the same. 


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).


Code coverage 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.

4. Design/Development Constraints
There are so many design constraints and principles for software development. Some of them are:

  • 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 We separated 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. 
Published at DZone with permission of Cagdas Basaraner, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Balint Persics replied on Wed, 2012/10/10 - 2:14am

"You can also see that there are 3 different paths from leftmost node to rightmost node"

Actually there are 4 paths. 

Stephane Vaucher replied on Thu, 2012/10/11 - 10:54am in response to: Balint Persics

Well the graph is undirected, so it is a bit confusing, but not as much as the definition of independent paths. They are not meant to each connect the source and the sink. That said, there are three independent paths because they cannot overlap.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.