Write review rules
Documentation Index
Fetch the complete documentation index at: https://docs.sourcery.ai/llms.txt
Use this file to discover all available pages before exploring further.
Most teams already have the raw material for review rules written down somewhere. A style guide, the conventions section of an engineering handbook, a pull request checklist, or just the three things you find yourself repeating in review every week. A review rule takes one of those, states it in plain language, and scopes it to the files it applies to.
Rules live on the Review rules tab of Review Settings. They’re available on all plans, and were previously called custom rules.
Write a rule
Section titled “Write a rule”-
Open the Review rules tab
Go to Review Settings and open the Review rules tab.
-
Set the path patterns
Add one or more globs under Path patterns, such as
src/api/**. The rule applies only to files that match. Not sure how narrow to go? Leave it broad to apply everywhere. -
Write the rule
Describe what Sourcery should check in the Rule field, which takes up to 3,000 characters of free-form text. Be specific about what good and bad look like.
How a rule changes a review
Section titled “How a rule changes a review”Sourcery checks the rule against every changed file its path patterns match. Where the code falls short, you get an ordinary inline comment on the line in question, carrying the same type (area): prefix as the rest of the review, with the rule quoted underneath so you can tell which one produced it.
A rule adds to a review rather than narrowing it. Sourcery still raises the bugs and issues it would have raised on those files anyway, and a rule only ever looks at what the pull request changes, not the rest of the repository.
Example rules
Section titled “Example rules”From your style guide
Section titled “From your style guide”Path patterns: **
Every new public function needs a docstring that explains its purpose. Flag any new public function without one.
From your naming conventions
Section titled “From your naming conventions”Path patterns: src/**/*.tsx
Custom React hooks must be named with a
useprefix and live insrc/hooks. Flag any hook declared elsewhere or named without the prefix.
From your architecture rules
Section titled “From your architecture rules”Path patterns: src/api/**
Endpoints must validate request input before using it. Flag any handler that reads request data without validating it first, and suggest the validation to add.
From a migration in flight
Section titled “From a migration in flight”Path patterns: **/*.py
We are migrating from
requeststohttpx. Flag any new code that importsrequestsand suggest thehttpxequivalent.
Each one says what to flag and what you want instead, which is what separates a rule Sourcery can act on from a sentence of good intentions.