What should you check before accepting a code change?
Read the changed lines, run the checks that apply to them and try the affected action with test data. Each check answers a different question.
Which checks help with style, mistakes and actual app behavior?
A formatter makes the layout consistent. A linter reads code for configured patterns. Other checks look for exposed credentials or issues in packages your app uses. Use a test of the app action to see whether the change did what you intended.
For a shipping estimate, start by reading the changed lines. Then try the example from the change request, such as two items that should ship for one combined charge.
How do you tell whether a green check is looking at the right files?
Start by asking which files and rules the check covers. On a disposable copy, use one known example that should be caught and a clean example that should pass. If both pass, check whether the rule was enabled and the file was included.
Ask where the check runs. A local run reads the files on that machine. A hosted check or review can have its own access to the repository. Check that boundary before connecting a private project.
Compare tools
Scroll the table sideways to read every column.
| Tool | What it checksThe kind of problem it helps you look for. | What the check doesWhat it reports and when it writes changes. | What to keep or confirmThe setup that makes the result repeatable. | What costs moneyThe tool license and other operating costs. |
|---|---|---|---|---|
| ESLint | Configured code rules for JavaScript, with extensions for additional use cases. | Reports where a rule finds a pattern. Automatic fixes can write files when enabled. | Keep the settings and rule dependencies. Confirm the installed version and rule on a known example. | MIT-licensed local tool. Hosted check time is separate. |
| Prettier | Consistent formatting of supported source files. | Check mode lists files with style differences. Write mode reformats them. | Keep the version and settings with the project. Check style and app behavior separately. | MIT-licensed local tool. Hosted check time is separate. |
| Biome | Formatting, lint and configured assist checks for supported web files. | Run checks before writes. Verify which rules and file types are covered. | Compare important rules before switching. Migration does not preserve every rule or option. | MIT or Apache 2.0 open source. Hosted check time is separate. |
| Ruff | Lint and format Python source. | Report selected lint rules or formatting differences. Enable writes separately. | Keep shared rules, Python target and tool version. | MIT tool. Budget separately for a build runner. |
| Pyright | Check Python type assumptions. | Report mismatches before the app runs. | Keep the Python version, dependency environment and type settings consistent. | MIT tool. Running your checks may have its own cost. |
| GitHub Dependabot | Propose package updates in a GitHub repository. | Open pull requests for configured versions or eligible security updates. | Keep package locations, update schedule and review checks with the repository. | Version updates are available to all GitHub repositories. Check test-runner costs separately. |
| Renovate | Schedule and group package updates across supported repositories. | Open update pull requests. Use approval gates on supported platforms if needed. | Keep package rules and repository access narrow. Review before using automatic merging. | Compare the open-source CLI running costs with Mend-hosted or separately licensed editions. |
| Gitleaks | Look for credential-like text in your own source or history. | Report matches for a teammate to check. Replace any exposed real credential separately. | Keep the scan scope and rule settings. Use labels without copying secret values. | The core is MIT-licensed. Check separate Action terms and runner costs. |
| CodeRabbit | Add automated comments to a proposed code change. | Suggest issues for a person to review against the actual app. | Confirm repository access, code processing and what review context is retained. | Compare developer seats, included hourly reviews and optional usage charges. |
| Semgrep | Check your own source against selected patterns. | Report potential issues for review and correction. | Keep scan scope and rule versions. Check engine and rule terms separately. | Local Community Edition engine is open source. Managed plans use separate contributor and credit rules. |
What should you read after a tool or agent changes code?
Read the difference between the old and new versions, sometimes called a diff. Check that the change addresses the reported issue and leaves unrelated files alone. Repeat the check and try the app action it affects.
Keep write mode separate from report mode. If checks will block a merge, start with a focused set your team knows how to investigate, including who reviews a finding before anyone disables a rule.
How can you rehearse a review without touching your app?
Use paper notes for a fictional delivery page. No repository, hosted check, credential or live app is involved.
- Split the findingsWrite three issues: uneven indentation, a reference to a misspelled code name and a wrong delivery total.
- Choose the check for eachMark style check for the spacing, the applicable code rule for the name and an app test with a known correct total.
- Review a pretend fixRead the changed line and verify the expected total again. If the test case is still untested, leave behavior unverified.