code metrics

The vices and virtues of the code metrics

A geeky way to make your product more testable, reliable, and maintainable is to introduce code metrics into your development process. We explain how to benefit from them and why metric-centric approach is not a good idea.
Code analysis is an integral part of any software development life cycle. The industry can boast a bewildering variety of tools and methods to carry out an effective code analysis, and metrics are one of them.

Analysis turns complex technical notions into understandable figures and graphs and shows a clear picture of what is going on in the code.

There are six reasons why it's worth giving a try:
Metrics help determine the software quality. Especially if coupled with other quality assurance techniques, they add great value to estimating the overall success of the output software and its readiness for production. Measurements show the real performance rates and adequate evaluation of quality at each stage of project development.
Statistical data helps structure development strategies. Imagine a product team inherits a 5-year-old project from another department that must be revamped to keep up with the latest trends in the industry. How complex is the codebase? Is there much legacy or orphaned code? Do we have enough workforce to meet the deadlines? Metrics will answer these questions.
Metrics explicitly indicate weak points. Detecting weaknesses in the system architecture or development processes can help you eliminate pitfalls before the production. It also helps identify areas that need refactoring. For example, high cyclomatic complexity results may reveal untestable code and overcomplicated architecture.
Though mainly targeted at developers, comprehensive code analysis results are of great value for the management, if presented visually.
Metrics reduce the risks. Poor maintainability rates may result in difficulties when adding functionality on further stages of the project development, when your team may end up rewriting the whole program from scratch.
Using metrics is cost-efficient. The earlier problematic areas are detected, the simpler the fix. If treated right, metrics enable effective management and boost team productivity, and make troubleshooting much cheaper.
Metrics are objective and it's easier for management to give judgement and perform reviews.
The Dark Sides of Metrics
Some are prone to shifting their focus from results to figures. For the management, software metrics is a tool to quickly asses the dev team performance, but the assessment cannot be based on the metrics exclusively. Unsatisfactory measurement results often put pressure on the dev team and distract from coding. To keep up with the management's expectations, developers sometimes tend to consider good indicators to be more important than the real value of the work being done.

Other organizations unlink metrics from real goals. For example, thoughtless reduction of lines of code in a function to meet the requirements might increase the system's complexity instead of decreasing it.
Oversimplifying software metrics is another common mistake. It's easy to make false conclusions by comparing separate data points without understanding the dynamics. In fact, the trend is what really matters...
Software metrics are important but should not be time-consuming to implement and run. It should be a quick and comprehensive solution that would not interfere with the development and distract developers from writing code and solving top-priority issues. That's why we made the static Code Analyzer one of the core engines in all Conquest products. Along with code review, formatting, and illustrating, this engine calculates code metrics for PL/SQL code.
The measurements are based on four metrics: Maintainability Index, Cyclomatic Complexity, Halstead Volume, and Interface Complexity, which are calculated using more minor metrics such as Lines of Code, Comment Percent, Halstead Program Length, Vocabulary, Difficulty, and Effort, and the like.
These metrics are targeted at the evaluation of software quality by measuring its technical characteristics and identifying areas that can potentially cause problems or errors. They are also good at detecting legacy code and segments for refactoring. The metrics are adjustable to your corporate requirements, meaning you can set the necessary limits, like maximum Maintainability Index value, and the areas where the limits are exceeded will be marked to draw extra attention.

If you do care about that quality of your software, its success, and the ultimate satisfaction of your end users, consider introducing code metrics into your development life cycles and make them work for you.

When coupled with strong code review techniques, smart quality assurance methodologies, and consistent performance checks, code metrics can become another valuable instrument to achieve high software quality and make you feel proud of the solutions you provide.
Code metrics in ClearDB Documenter