For the latest updates and improvements, see the latest Cloud documentation instead.
Configuring code patterns#
By default, Codacy uses a subset of the supported static analysis tools and code patterns to analyze your repositories. These default settings result from community feedback or existing coding standards. However, you can adapt the default settings to your scenario by configuring the tools and code patterns that Codacy uses to analyze your repository.
Note
If your repository is following an organization coding standard, changes made to any tool or code pattern cause the repository to stop following the coding standard. In this case Codacy asks for your confirmation before accepting the changes.
To configure the tools and code patterns for your repository:
-
Open your repository Code patterns page.
-
Toggle the tools that Codacy will use to analyze your repository.
-
Select each tool to configure and enable or disable the corresponding code patterns using the checkbox next to each pattern.
To see an explanation of the issues that a pattern detects and how to fix them, click Show details. Some patterns also allow you to configure the rules for detecting issues.
-
Optionally, manually reanalyze your repository to immediately take the changes into account. Otherwise, Codacy will use the new configuration when it analyzes a new commit or pull request.
Tip
Organization owners can change who is allowed to configure code patterns.
Pattern filters#
To make it easier to find relevant code patterns, you can use the sidebar to filter the patterns by language (only for tools that support multiple languages), category, or status:
Tip
To enable all code patterns matching a specific category, use the filter to select the relevant patterns and click Enable all.
For example, to enable all Security patterns of a tool, you can use the Security filter and click Enable all.
Issues detected by Codacy belong to one of the following 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
==in JavaScript orOption.getin Scala - 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
Importing pattern configurations from another repository#
Importing tool and code pattern configurations from another repository can help you bootstrap and standardize the tool and code pattern configurations across your repositories.
For example, when adding a new repository on Codacy you can copy the tool and code pattern configurations from an existing repository that's already configured, and then tweak and adapt the settings for your new repository.
Tip
To ensure that multiple repositories consistently follow the same global tool and code pattern configurations, use an organization coding standard instead.
Alternatively, you can also copy the tool and code pattern configurations from one repository to multiple target repositories.
Important
Consider the following when using this feature:
- Tool matching: Codacy only copies settings for tools that are available on both the source and target repositories, and overwrites the existing settings for these tools on the target repository.
- Toggle status: Codacy copies the enabled or disabled status of the matching tools from the source to the target repository.
- Configuration files: Codacy copies the UI configuration of all matching tools, even those set to use configuration files. However, the import doesn't include the configuration mode itself.
The following example illustrates the points above:
| Source repository | Target repository | Target repository after import |
|---|---|---|
 |
 |
 |
To import the tool and code pattern configurations from another repository:
-
Open your repository Code patterns and click Import patterns.
-
Follow the instructions to select the source repository and complete the import.
-
Review and adjust your tool and code pattern configurations if necessary.
Codacy will use the updated configurations on the next analysis.
Using your own tool configuration files#
Codacy supports configuration files for several tools. To use a configuration file for your static analysis tool:
-
Push the configuration file to the root of the branch configured as the main branch on Codacy.
-
Open your repository Code patterns page, select the tool that will use the configuration file, and select the option Configuration file.
After activating the option to use the configuration file:
- Codacy will use the version of the configuration file in the branch being analyzed. For example, if you open a pull request that includes changes to the configuration file, the analysis results will take those changes into account.
- If Codacy analyzes a branch that doesn't include the configuration file, Codacy reverts to using the code patterns configured for the tool before you selected the option Configuration file on the Code patterns page.
The table below lists the configuration file names that Codacy detects and supports for each tool:
| Tool name | Language | Files detected | Other info |
|---|---|---|---|
| Ameba | Crystal | .ameba.yml |
|
| Bandit | Python | bandit.yml, .bandit |
To solve flagged valid Python "assert" statements, create a bandit.yml in the root of the repository containing: skips: \['B101'\] |
| Brakeman | Ruby | config/brakeman.yml |
|
| Checkstyle | Java | checkstyle.xml |
Supports configuration file in directories other than root and can search up to 5 directories into the repository. |
| CodeNarc | Groovy | .codenarcrc |
|
| Credo | Elixir | .credo.exs, config/.credo.exs |
|
| CSSLint | CSS | .csslintrc |
|
| dartanalyzer | Dart | analysis_options.yml |
Customizing static analysis |
| detekt | Kotlin | default-detekt-config.yml, detekt.yml |
Supports configuration file in directories other than root and can search up to 5 directories into the repository. |
| ESLint | JavaScript, Typescript | .eslintrc.js, .eslintrc.cjs, .eslintrc.yaml, .eslintrc.yml, .eslintrc.json, .eslintrc,
.prettierrc, .prettierrc.yaml, .prettierrc.yml, .prettierrc.json, prettier.config.js, .prettierrc.js |
Plugins in the UI Other Plugins |
| Hadolint | Dockerfile | .hadolint.yaml |
|
| JSHint | JavaScript | .jshintrc |
|
| markdownlint | Markdown | .markdownlint.yaml, .markdownlint.jsonc, .markdownlint.json |
|
| PHP_CodeSniffer | PHP | phpcs.xml, phpcs.xml.dist |
|
| PHP Mess Detector | PHP | codesize.xml, phpmd.xml, phpmd.xml.dist |
|
| PMD | Apex, Java, JavaScript, JSP, PL/SQL, XML, Velocity and Visualforce | ruleset.xml, apex-ruleset.xml |
Supports configuration file in directories other than root and can search up to 5 directories into the repository. |
| Prospector | Python | .prospector.yml, .prospector.yaml, prospector.yml, prospector.yaml, .landscape.yml, .landscape.yaml, landscape.yml, landscape.yaml |
|
| Pylint | Python | pylintrc, .pylintrc |
Plugins |
| remark-lint | Markdown | .remarkrc, .remarkrc.json, .remarkrc.yaml, .remarkrc.yml, .remarkrc.js |
|
| Revive | Go | revive.toml |
|
| RuboCop | Ruby | .rubocop.yml |
|
| Scalastyle | Scala | scalastyle-config.xml, scalastyle_config.xml |
|
| Sonar C# | C# | SonarLint.xml |
|
| Sonar VB | Visual Basic | SonarLint.xml |
|
| Spectral | AsyncAPI, OpenAPI | .spectral.yaml, .spectral.yml, .spectral.json |
|
| SpotBugs | Java, Scala | findbugs.xml, findbugs-includes.xml, findbugs-excludes.xml, spotbugs.xml, spotbugs-includes.xml, spotbugs-excludes.xml |
Supports configuration file in directories other than root and can search up to 5 directories into the repository. |
| Stylelint | CSS, LESS, SASS | .stylelintrc, stylelint.config.js, .stylelintrc.json, .stylelintrc.yaml, .stylelintrc.yml, .stylelintrc.js |
Supports configuration file in directories other than root and can search up to 5 directories into the repository. |
| SwiftLint | Swift | .swiftlint.yml |
|
| Tailor | Swift | .tailor.yml |
|
| TSLint | TypeScript | tslint.json |
|
| TSQLLint | Transact-SQL | .tsqllintrc |
Note
Codacy doesn't support configuration files for the following tools:
- aligncheck
- bundler-audit
- Checkov
- Clang-Tidy
- Codacy ScalaMeta Pro
- CoffeeLint
- Cppcheck
- deadcode
- Faux Pas
- Flawfinder
- Gosec
- Jackson Linter
- PSScriptAnalyzer
- ShellCheck
- SQLint
- Staticcheck
For performance reasons, if you make changes to pattern settings using configuration files, Codacy may display outdated messages for issues that have already been identified by those patterns.
See also#
- Applying a coding standard across multiple repositories
- Copying code patterns between repositories
- How to implement Google JavaScript style guide with Codacy
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.
If you have a question or need help please contact support@codacy.com.