Embold rating system
The Embold rating system is a numeric representation of the quality of software. The rating is calculated on every level of the software: for a function (or method), a component (or class), a package and for the overall software.
Embold rating ranges from -5 to 5, where -5 indicates a poor quality software whereas, 5 indicates an extremely good piece of software.
At the time of writing this article the Commons-Text repository for version 1.2 had an overall rating of 2.74, which is quite good.
The rating is shown on a project and on a repository level inside of the colored circle. This helps you to quickly compare the quality between your projects and repositories once you have more than one scanned.
Calculating Embold rating
The overall rating is derived from four sub-ratings: Design (anti-pattern), Metrics, Duplication and Code Quality (code issues). These sub-ratings are again calculated for all components (functions or classes) and then aggregated for packages (or modules) and for the overall repository. Our proprietary quality parameters specifies how each sub-ratings is weighted in order to derive the overall Embold rating.
Code Metrics are measures for quantitatively assessing your source code. Embold calculates a large number of metrics, i.e. Lines of Code, Cyclomatic Complexity or Depth of Inheritance hierarchy. For each metrics, there are pre-defined thresholds that are documented on the metrics section of the documentation. The more a certain metric is breached, the bigger the negative impact on the Embold rating.
Duplication defines how much of your code is duplicated in one or more places. The higher the duplicated code, the more impact on the core.
Code issues are detected by checking the code against pre-defined rules. Each code issue has a severity as critical, high, medium or low. Critical issues have a higher impact on the rating than low severity issues obviosuly!
Design and architecture
Design and architecture of your code are evaluated by detecting anti-patterns which identify structural issues within your source code. There are function/method level design issues and component level design issues. Component level design issues have a significant impact on the rating. Additionally, each design issues is assigned high, medium, or low severity. High severity design issues have a significant impact than low severity issues.
Embold rating use cases
There are many use cases for Embold rating. Few of the use cases are explained here. One of them is comparing the overall quality of different software projects and repositories
A second use case is tracking the quality of one software repository over time. The overall rating gives a very quick overview over improvements or deteriorations in the quality and helps to establish a continues quality improvement process. Even for non software developers that makes software quality understandable, and helps to track certain projects or software suppliers over time.
As a third use case, the Embold rating enables development managers to easily allocate resources. The way the rating is calculated out of four sub-metrics it provides insights into what part of the development team needs training or additional support. If the design rating is bad an additional software architect might be required. If the code issues or metrics rating is bad, training no certain programming principles might be helpful. A bad duplication rating is in indicator for suboptimal code organization, documentation or team structure.
Embold Risk Score
What is Embold Risk Score?
The Embold risk score signifies the urgency of addressing the quality problem on priority. The Embold risk score ranges from 5 to 1, where 5 represents high risk and 1 represents a low risk.
How is the Embold Risk score calculated?
To calculate the risk score Embold considers the frequency of changes, the number of issues and severity of issue tickets raised against a specific component (or class).
For Version Control System only, the risk score is calculated from the number of commits weighted by the age of each commit. The more recent a commit is, the higher the impact on the risk score. Each commit and its age will be calculated.
Example: A file with 20 commits, all in the last month, has a higher risk than a file with 20 commits a year ago.
If the Embold is integrated with the ticketing system then more data is available. To calculate the risk score, at the time of scanning Embold considers all the tickets that had commits to the file. The impact on the risk score is based on the criticality of the ticket.
Example: A year-old Blocker Bug will create more Risk than a one-month-old Trivial Feature. In this equation, time is no factor because the criticality still applies, if the ticket haven’t been deleted.
Why refactoring is important while calculating the risk score?
If a bad code is not modified frequently, it has a smaller impact on the overall system. The rule of thumb is: if you modify a file more than five times, refactor it to obtain an average positive return on investment. Learning from the Version Control System and Jira history of each file, with risk score Embold determines where the code has a higher possibility of changes and its importance on the overall system.