Which metrics does Codacy calculate?#
Codacy performs static code analysis and calculates code duplication, code complexity, and code coverage metrics for most supported programming languages.
The following sections describe how Codacy calculates each supported metric and where you can see each metric on the Codacy UI:
Depending on certain characteristics of your repository, such as the number of source code files and their size, Codacy may apply limits to the code analysis that impact the calculation of the supported metrics.
Codacy assigns an overall grade to your repository branches and to individual files to help you assess the code quality of your repository. Grades represent a weighted average of the available code quality metrics (issues, complexity, duplication, and coverage), and range from A to F:
|Highest grade||Lowest grade|
Codacy displays grades on the following places:
|Files page||Grade for each file in your repository|
|Grade of each analyzed branch in your repository|
|Email notifications||Grade of your repository|
|Organization Overview||Average grade of the repositories in your organization and grade of each repository|
|Repositories list||Grade of each repository in your organization|
Codacy calculates the number of issues in the following static code analysis categories:
- Code Style: Code formatting and syntax problems, such as variable names style and enforcing the use of brackets and quotation marks
- Error Prone: Code that may hide bugs and language keywords that should be used with caution, such as the operator
- Code Complexity: High complexity methods and classes that should be refactored
- Performance: Code that can have performance problems
- Compatibility: Mainly for frontend code, compatibility problems across different browser versions
- Unused Code: Unused variables and methods, code that can't be reached
- Security: All security problems
- Documentation: Methods and classes that don't have the correct comment annotations
Besides this, Codacy also allows you to compare issues across repositories with different sizes by calculating the percentage of issues relative to an expected baseline of 100 issues with an average cost of 10 per 1000 lines of code, where the cost of each issue depends on its severity: Critical = 10, Medium = 5, Minor = 1.
Codacy displays issues on the following places:
Pull requests page
|Number of new and fixed issues introduced by the commit or pull request|
|Files page||Number of issues in each file|
|Issues page||List of all issues detected in each branch|
|Repository Dashboard||Issue percentage and how the metric is evolving over time|
|Organization Overview||Average issue percentage of the repositories in your organization and issue percentage of each repository|
|Repositories list page||Issue percentage in each repository in your organization|
Codacy uses cyclomatic complexity to identify files with complex methods in your repository. Cyclomatic complexity is the number of linearly independent paths through the source code of a method: the more control flow statements used in a method, the higher the value. Methods with a high cyclomatic complexity are more difficult to test and more likely to have defects. Learn more about code complexity on Codacy's blog.
Codacy calculates complexity as follows:
- The complexity value for each file is the highest cyclomatic complexity of the methods in the file.
- A file is considered complex if its cyclomatic complexity value is higher than the threshold File is complex when over.
- The complexity value of a commit or pull request is the sum of the cyclomatic complexity of the files that were changed in the commit or pull request and that have complexity higher than 4.
Codacy displays complexity on the following places:
Pull requests page
|Variation of the complexity value introduced by the commit or pull request|
|Files page||Complexity value of each file|
|Repository Dashboard||Percentage of complex files in your repository and how the metric is evolving over time|
|Organization Overview||Average percentage of complex files in the repositories in your organization and percentage of complex files in each repository|
|Repositories list page||Percentage of complex files in each repository in your organization|
Codacy identifies clones or sequences of duplicate code that exist in at least two different places of the source code of your repository. Clones typically indicate deeper code quality issues and should be eliminated through abstraction when possible.
Codacy calculates duplication as follows:
- The duplication value for each file is the number of clones in the file.
- A file is considered duplicated if the number of clones in the file is higher than the threshold File is duplicated when over.
- The duplication value of a commit or pull request is the number of clones introduced by the commit or pull request.
You can customize the rules for identifying duplicated blocks of code when using PMD CPD to analyze the source code of your repository.
Codacy displays duplication on the following places:
Pull requests page
|Number of clones added or fixed by a commit or pull request|
|Files page||Duplication value of each file|
|Repository Dashboard||Percentage of duplicated files in your repository and how the metric is evolving over time|
|Organization Overview||Average percentage of duplicated files in the repositories in your organization and percentage of complex files in each repository|
|Repositories list page||Percentage of duplicated files in each repository in your organization|
Code coverage describes the degree to which the source code of a program is tested. There are several types of coverage, but Codacy uses line coverage, which measures the percentage of coverable lines of code that are covered by automated tests. Learn more about code coverage on Codacy's blog.
You must set up your CI/CD pipeline to upload code coverage data to Codacy. Because of this, the tool that you use to generate the coverage reports is responsible for creating the data that Codacy then uses to calculate code coverage.
Codacy calculates code coverage as follows:
- The coverage value for each file is the percentage of coverable lines that are covered by tests in the file.
- A repository is considered to have acceptable coverage if the average coverage value for the files in the repository is higher than the threshold Coverage is under.
- The coverage variation of a commit or pull request is the number of percentage points that the coverage value for the file increased or dropped in the commit or pull request.
The diff coverage of a pull request is the percentage of coverable lines that the pull request added or modified that are covered by tests.
If a pull request doesn't add or modify any coverable lines, the diff coverage is
∅(not applicable). This scenario happens when the only changes in a pull request are:
- Deleted lines
- Added or modified lines that aren't coverable
Once the coverage setup is complete, Codacy displays coverage data on the following places:
Pull requests page
|Variation in percentage points of the coverage value for all files in the commit or pull request|
|Pull requests page||Diff coverage for the changes included in the pull request|
|Files page||Coverage percentage of each file|
|Repository Dashboard||Average coverage value for the files in the repository and how the metric is evolving over time|
|Codacy badge||Average coverage value for the files in your repository|
|Organization Overview||Average coverage of the repositories in your organization and coverage of each repository|
|Repositories list page||Coverage of each repository in your organization|
- Does Codacy place limits on the code analysis?
- Diff coverage: we have a new metric and quality gate rule for PRs
Share your feedback 📢
Did this page help you?
Thanks for the feedback! Is there anything else you'd like to tell us about this page?
255 characters left
We're sorry to hear that. Please let us know what we can improve:
255 characters left
Alternatively, you can create a more detailed issue on our GitHub repository.
Thanks for helping improve the Codacy documentation.
Edit this page on GitHub if you notice something wrong or missing.
If you have a question or need help please contact firstname.lastname@example.org.