Code Quality Metrics: Is Your Code Any Good?.

The SeaLights test metrics guide
for better and faster CI/CD

Code quality can have a major impact on software quality, on the productivity of software teams, and their ability to collaborate. But how can you measure code quality, to determine if your code is worth its salt?

This post covers quality metrics of two types: qualitative metrics, including maintainability, code readability and level of documentation; and useful automated, quantitative measurements of code quality, such as cyclomatic complexity.

You can use any of these metrics to evaluate your current quality level, and understand if it’s getting any better.

Optimizing Test Automation | Download White Paper >>

What is Code Quality and How Can You Improve it?

This is an attempt to approximate the value of code as either good or bad. Since almost every developer has his/her own definition of what constitutes good code, no single definition of quality exists.

Rather, a number of factors contribute to code quality in the same way that several factors affect writing evaluation. Continuing the analogy, writers often define good writing in their own unique way, but most writers agree on several factors that make good writing—coding is similar to writing and other art forms in this regard.

There are several ways to achieve high code value, such as:

  • Regular Code Reviews. According to a recent survey, software professionals rank code reviews as the number one way to improve programming. These reviews enable developers to collaborate and share knowledge with each other, which improves their work. Furthermore, reviews ensure that code adheres to established standards.
  • Functional Testing. Functional testing is important because it encourages developers to focus on software functionality from the outset, reducing extraneous code. The aim of software development is to write an application that delivers exactly what users need.
  • Clear Requirements. Most software development projects begin with a requirements document, or story cards in agile development. A project with clear, feasible requirements is much more likely to achieve high quality than ambiguous, poorly specified requirements.

Qualitative Code Quality Metrics

Qualitative metrics are subjective measurements that aim to better define what good means.


Extensibility is the degree to which software is coded to incorporate future growth. The central theme of extensible applications is that developers should be able to add new features to code or change existing functionality without it affecting the entire system.


Code maintainability is a qualitative measurement of how easy it is to make changes, and the risks associated with such changes.

Developers can make judgments about maintainability when they make changes — if the change should take an hour but it ends up taking three days, the code probably isn’t that maintainable.

Another way to gauge maintainability is to check the number of lines of code in a given software feature or in an entire application. Software with more lines can be harder to maintain.

Readability and Code Formatting

Readable code should use indentation and be formatted according to standards particular to the language it’s written in; this makes the application structure consistent and visible.

Testing: The Next Bottleneck in Continuous Delivery | Download >>

Comments should be used where required, with concise explanations given for each method. Names for methods should be meaningful in the sense that the names indicate what the method does.

Image source


Clarity is an indicator of quality that says good code should be unambiguous. If you look at a piece of code and wonder what on earth it does, then that code is ambiguous.

This, along with readability and documentation,  means any other developer can easily use code written by someone else, without taking a long time to understand how it works.


If the program is not documented, it will be difficult for other developers to use it, or even for the same developer to understand the code years from now. One common definition of quality is that it may be “used long term, can be carried across to future releases and products” (without being considered “legacy code”). Documentation is essential to make this happen.

Documentation also provides a way to improve by formalizing the decisions you make when writing. When you document code and do it well, you need to think differently about each component and why it exists in the software. Writing out the reasons for certain programming decisions can improve application design.


Well tested programs are likely to be of higher quality, because much more attention is paid to the inner workings of the code and its impact on users. Testing means that the application is constantly under scrutiny.


Efficient code only uses the computing resources it needs to. Another efficiency measurement is that it runs in as little time as possible.

Many developers believe that inefficient code is not of good quality (even if it satisfies some of the criteria above). Some negative impacts of not building for efficiency is long build times, difficulty to detect and fix bugs, and performance issues for the user.

Quantitative Code Quality Metrics

There are a few quantitative measurements to reveal well written applications:

Weighted Micro Function Points

This metric is a modern software sizing algorithm that parses source code and breaks it down into micro functions. The algorithm then produces several complexity metrics from these micro functions, before interpolating the results into a single score.

WMFP automatically measures the complexity of existing source code. The metrics used to determine the WMFP value include comments, code structure, arithmetic calculations, and flow control path.

Halstead Complexity Measures

The Halstead complexity measures were introduced in 1977. These measures include program vocabulary, program length, volume, difficulty, effort, and the estimated number of bugs in a module. The aim of the measurement is to assess the computational complexity of a program. The more complex any code is, the harder it is to maintain and the lower its quality.

Cyclomatic Complexity

Cyclomatic complexity is a metric that measures the structural complexity of a program. It does so by counting the number of linearly independent paths through a program’s source code. Methods with high cyclomatic complexity (greater than 10) are more likely to contain defects.

With cyclomatic complexity, developers get an indicator of how difficult it will be to test, maintain, and troubleshoot their programming. This metric can be combined with a size metric such as lines of code, to predict how easy the application will be to modify and maintain.

Code Quality Metrics: The Business Impact

From a business perspective, the most important aspects of code quality are those that most significantly impact on software ROI. Software maintenance consumes 40 to 80 percent of the average software development budget. A major challenge in software maintenance is understanding the existing code, and this is where code quality metrics can have a big impact.

Consequently, quality code should always be:

  • Easy to understand (readability, formatting, clarity, well-documented)
  • Easy to change (maintainability, extensibility)

Beyond Code Quality: Monitoring Software Quality

Well written programming has a known impact on higher quality software. It’s not enough to measure code — it’s essential to understand and actually measure your software quality, and see if it is improving as a result of higher code quality.

Existing software testing tools do not provide a holistic picture of software quality. Most teams know their unit test coverage, but have much less visibility over the coverage and quality of their integration and acceptance tests.

SeaLights is a continuous testing platform that takes data from all your testing tools and gives you a holistic measurement of test coverage across the entire application. You can easily identify “Quality Holes”, functionality that is being worked on by developers but is not actively tested, which represents business risk. Learn more about the SeaLights platform.

Request A Demo