Filters

If you are interested in obtaining quality metrics for only a portion of your repository, the Filters functionality can be useful. This tool enables you to accurately delimit a section of your repository and obtain maintainability and test coverage metrics exclusively for the files enclosed by the defined code filter.

A code filter consists of a name and a set of inclusion patterns. An inclusion pattern specifies file names using wildcard characters.

Listing and creating code filters

Listing

For private repositories, you can access the Filters tab on your repository's page. This tab lists all of your created filters, and provides a button for defining new code filters.

Creating

Creating a new filter is easy. Keep in mind the area of the codebase you are interested in, and define its scope using a set of inclusion patterns. It may take a few moments for the application to crunch the numbers for the filter.

After creating a code filter, you can modify it by accessing the Filter Settings tab. There, you can both set a new name and modify the defined inclusion patterns.

📘

To define multiple inclusion patterns for your code filter, separate the patterns with a new line character (pressing enter) to separate each pattern definition.

Inclusion Patterns details

An inclusion pattern specifies files to include using wildcard characters. This technique is commonly referred to as glob patterns. These patterns refer to filenames relative to the project root. Below you can find our supported list of wildcards along with a few examples of valid inclusion patterns.

• * matches any number of any characters including none, eg; Law* matches Law
  , orLawyer but doesn’t match GrokLaw, La, or aw
• ? matches any single character, eg; ?at matches Cat ,Batorbat but doesn’t match at
• [abc]matches one character given in the bracket, for example[CB]at matches Cat
  orBat but doesn’t match cat, bat or CBat
• [a-z]matches one character from the (locale-dependent) range given in the bracket, eg; Letter[a-c] matches Lettera, Letterb and Letterc but doesn’t match Letterd

Here are some examples of valid inclusion patterns:

• controllers/users/*.js
• controllers/**/*.js
• **/*.js
• *.rb

🚧

Inclusion patterns shouldn’t include a leading slash because they are relative to the project's root. This means that /controllers/users/.js is invalid and should be changed to controllers/users/*.js.

Known use cases

The Filters functionality aims to help identify the distribution of technical debt across an application. Below is a list of several different approaches that can serve as inspiration for creating filters.

• Application Architecture: For applications with a well-defined architecture, it can be helpful to define a filter for each layer of the application. For instance, in an MVC-based application like a Ruby on Rails project, you could create one filter for each layer.

• Monorepo: When the source code of different projects is located in the same repository, it can be difficult to determine the maintainability rating of a specific project within the monorepo. With Filters, you can define a filter for each project in the repository and obtain top-level quality ratings for them.

• Teams: If there are different groups of developers working on different areas of the repository, you may want to consider creating a dedicated filter for each group.

• Ratings by language: If a project uses multiple programming languages, it is easy to obtain dedicated quality ratings for each language by creating a separate filter for each language.

• Identify problematic sections: To confirm theories about which sections of your application are most challenging to maintain, consider creating specific filters for those areas that are causing concern.

• Divide and conquer: Reducing an application's technical debt can be an overwhelming task. However, Filters allow you to target specific areas of the codebase, concentrate your efforts on those areas, and track your progress.

FAQ

• Which files are considered by the inclusion patterns?
  • Only files that are present in your repository and have been analyzed by CodeClimate. This means that anything you have excluded from analysis using our exclusion mechanism will be ignored.
• Who can modify filters?
  • Any user with read access to the repository.
• Are filters always up-to-date?
  • Yes, code filters metrics are updated in the background every time we process a new analysis for the repository. This usually happens after you push a new commit to your repository.
• Where are the other metrics, such as "churn vs maintainability"?
  • The Filters feature was recently introduced and will be improved and enhanced as we collect feedback. If you have any requests or feedback, please contact us at [email protected].