Using Multiple Rule Sets in code-health-rules.json – How Rule Order Impacts Code Health Analysis

When customizing CodeScene’s Code Health analysis, the code-health-rules.json file allows you to define multiple rule sets targeting different parts of your codebase. This is especially useful when you want different thresholds or rules for production code, test files, or specific modules. However, rule order matters - and understanding this is key to ensuring accurate analysis.

Rule Matching is First-Come, First-Serve

In CodeScene, only the first matching rule set in the list applies to a file. Once a file matches a matching-content-path, no subsequent rules are considered. This means ordering your rules correctly is critical.

Let’s consider this example:

At first glance, it may seem like test files would get their own duplication threshold. However, this setup doesn’t work as intended. Why?

Because "**/*" matches everything in the repository - including test files - before the second rule has a chance to apply. As a result, the test-specific duplication rule is ignored.

The Fix: Reorder Rule Sets by Specificity

To ensure specific rules apply correctly, always place more specific rules before general ones. Here’s the corrected example:

Now:

• Test files get a relaxed duplication threshold.

• They still adhere to the max constructor argument rule.

• All other code follows the general rules.

Best Practices for Multiple Rule Sets

1. Order by specificity – List the most narrowly scoped rules first (e.g., test folders, modules).

2. Keep "**/*" last – This ensures it acts as a fallback rule.

3. Duplicate rules if needed – If a rule should apply across scopes, include it in each relevant rule set.

4. Use meaningful globs – Be precise in defining matching-content-path to target files accurately.

By following these practices, you ensure your Code Health configuration reflects your intentions and gives your team meaningful, actionable results across different areas of the codebase.