Following are three different aspects of software quality which could be tracked using Sonar Dashboard:
Following are different data elements that you could take from sonar dashboard and govern different aspects of software quality as mentioned below:
Complexity represents code complexity which, in turn, represents code cyclomatic complexity. Over a period of time, if complexity (of methods or class) increases, it depicts following:
Following diagram represents the code complexity in terms of cyclomatic complexity. In the following, code complexity per method is 2.0 and per class is 12.9. A code complexity of 10 or less is allowable for method or else, a code violation flag is raised.
Sonar dashboard comes with rules compliance violations. One of the key things one could use this data is to watch out for security related violations. That said, one may want to use different security-related tool for this purpose. However, I have found it to be useful to watch out for security related coding violations as it serves the purpose sufficiently. From code quality perspective, it would be good to watch out for blocker and critical violations. It does come out with coding violations (against the configured code profile) developers ended up making with their code. Over a period of time, one could watch out for delta (changed) and report the team with frequently occuring violations. Following diagram represents the rules violations. Watch out for numbers related with blocker, critical, major, minor and info.
Duplication (represented in %) depicts the duplication of block of codes and files. It does impact the maintainability. Higher the duplication percentage, lower is the code maintainability. One should watch out for increase in code duplication and report to the team appropriately. Following diagram represents duplication in percentage.
LCOM suspects are the files which has cohesion index (LCOM4) greater than 1. The value of LCOM4 is represnted in terms of number/class. For example, 2.5/class. This means that on an average, a class is doing 2.5 things. In simple words, these are files which violates single responsibility principle (SRP) which says that a class should do just one thing, or a class should have just one reason to change. Thus, higher percentage of files having LCOM4 > 1 impacts the maintainability in following ways:
Thus, one should watch out for LCOM4. Following diagram represents the LCOM4 index. Following represents the fact that 27.1 % files have LCOM4 > 1 which implies that 27.1% files tends to violate single responsibility principle.
This is pretty straight forward. Test coverae is measured as unit test coverage. Higher the unit test coverage, higher the maintainability. One should watch out for ways unit test coverage changes and report to the team appropriately. Following diagram represents the unit test coverage.
Very simple to understand, documentation is key component of making your code easy to understand, e.g., usability. It is denoted in percentage. Over a period of time, an increase in documentation would mean that code usability is increasing as code may be understood well with the help of documentation. Following diagram represents the documentation in percentage.
In recent years, artificial intelligence (AI) has evolved to include more sophisticated and capable agents,…
Adaptive learning helps in tailoring learning experiences to fit the unique needs of each student.…
With the increasing demand for more powerful machine learning (ML) systems that can handle diverse…
Anxiety is a common mental health condition that affects millions of people around the world.…
In machine learning, confounder features or variables can significantly affect the accuracy and validity of…
Last updated: 26 Sept, 2024 Credit card fraud detection is a major concern for credit…