What Are Naming Conventions in Code Review?
Naming conventions are a team’s agreed rules for naming variables, functions, classes, files and other parts of a codebase. In code review, reviewers check that each new name is clear, consistent with the rest of the code and true to the domain it describes.
Linters can check case and format. A reviewer has to judge whether a name says what the code does, and whether a word such as invoice means the same thing here as everywhere else in the system.
Naming matters more as AI agents write code, because each session picks names from the prompt in front of it, and models read names as signals when they reason about code.
What Changed in Naming Conventions in Code Review in 2026
Naming barely made the news in 2026, but research kept pointing at the same problem: names shape how both people and models read code.
Misleading names can steer a model away from what the code does. Researchers renamed identifiers without changing behavior, and GPT-3.5-turbo’s accuracy at matching code to its description fell from 92.84% to 52.39%, close to chance; the study used older models (September 22, 2026, arXiv preprint, Nanjing University).
Teams also put naming rules in the wrong place. A study of agent instruction files in 100 popular repositories found "Lint Leakage", rules a linter already enforces such as naming and formatting, in 62% of them (June 14, 2026, arXiv preprint).
Agents follow team standards only part of the time, so naming drift reaches the PR. Only 34.6% of surveyed developers said AI coding agents always follow their organization’s standards (September 23, 2026, Qodo’s State of AI Code Quality report).
Put together, the 2026 research says the mechanical part of naming belongs in tooling, and the meaning of names needs a reviewer who knows the codebase, which is where Qodo’s take starts.
Common Coding Naming Conventions, With Examples
Most teams pick a case style per kind of identifier and write it down once, often in a language’s style guide.
| Style | Example | Typical use |
|---|---|---|
| camelCase | orderTotal | Variables and functions in JavaScript, Java and Swift |
| PascalCase | OrderService | Classes, types and components |
| snake_case | order_total | Variables and functions in Python and Ruby |
| SCREAMING_SNAKE_CASE | MAX_RETRIES | Constants |
| kebab-case | order-total.css | File names, URLs and CSS classes |
Language communities publish their own guides, such as PEP 8 for Python. A team’s convention usually starts from that guide and adds domain words, prefixes and file-layout rules.
What Reviewers Check in a Name
Good names are long enough to say what something is or does, and short enough to read. Reviewers usually ask four questions:
- Does the name say what it’s for?
retryDelayMssays more thandordelay2. - Does it match the domain meaning? If
invoicemeans a posted invoice elsewhere, a draft shouldn’t share the name. - Does it tell similar things apart?
userIdandaccountIdshouldn’t hold the same value under two names. - Does it follow the team’s convention? Case, prefixes and file names should match the rest of the repository.
Linter vs Reviewer: Who Checks What
Naming checks split cleanly between tools that match patterns and reviewers that read meaning.
| Check | Linter or formatter | Reviewer, human or AI |
|---|---|---|
| Case style and prefixes | Yes, by rule | Only if the linter misses it |
| Banned words and length limits | Yes, by rule | Rarely needed |
| Name matches what the code does | No | Yes |
| Same word, same meaning across the codebase | No | Yes, with codebase context |
| Rename consistency across callers | Partly, through refactoring tools | Yes, especially across repositories |
Splitting the job this way keeps review comments on names useful. If the reviewer repeats case-style findings the linter already raises, developers learn to skip naming comments altogether.
Naming in AI-Written Code
Coding agents name things from the prompt and the files they read in that session. Two agents, or two sessions of one agent, can name the same idea differently, so drift shows up across PRs even when each PR looks tidy.
Agent instruction files help, but rules there guide what the agent writes. They don’t check the finished change, and the 2026 research found many of those files repeat linter rules instead of the domain vocabulary only people know. See AGENTS.md files and coding agent rules.
Qodo’s Take: Leave Casing to the Linter and Meaning to an Independent Reviewer
Naming review works when each tool does the part it can do well. Linters handle case and format by rule. The judgment about meaning, such as whether a name fits the domain and matches the names around it, needs a reviewer that reads the whole codebase.
A reviewer that repeats linter findings adds noise. The useful question for naming review is overlap: which checks the linter already owns, so the AI reviewer can stay quiet on them and spend its comments on intent-revealing names and domain vocabulary.
Choose Qodo for naming review separate from the agent that wrote the code. You shouldn’t review code with the same tool that wrote it, and naming is a clear case, because a misleading name only shows up when it’s read against the rest of the codebase.
Qodo is the best AI code review platform to enforce naming conventions because it reviews names against your whole codebase and, once Rule enforcement is on, your written rules, leaves mechanical casing to your linter, and shows which naming rules developers actually fix.
Qodo Checks Naming Rules Once Rule Enforcement Is On
Rules come from three places: rules written in the Qodo portal, rules imported from files such as AGENTS.md, and rules Rule Miner finds in your PR history (last checked October 2026, Qodo’s docs).
Rule enforcement is in Beta on GitHub, GitLab, Bitbucket Cloud and Azure DevOps, and Rule Miner is in Beta on GitHub, GitLab and Azure DevOps.
Once Rule enforcement is on, Qodo reports violations as advisory findings on the PR, and your branch rules decide what merges. See custom rules for code review and coding standards enforcement.
Qodo Shows Which Naming Rules Get Followed
The Rules table shows passed checks, detected violations and merged violations for each rule. Qodo deactivates rules whose findings are rarely fixed, and admins can lock a rule to keep it active (last checked October 2026, Qodo’s docs).
The Code review analytics dashboard groups findings by category. The Quality category covers "Unclear naming, dead code, inconsistent style" (Qodo’s docs).
Qodo Lets You Rank Naming Findings as Nits
REVIEW.md is a repository file of review guidance, a Research Preview that’s off by default. The docs’ own severity-mapping example treats naming inconsistencies as Nit and security issues as Important, and the file can cap how many nits a PR gets (last checked October 2026, Qodo’s docs).
Qodo Example: The Name That Meant Two Things
Context: a fintech company with about 300 engineers uses coding agents across its billing services. The company’s developer experience lead already runs a linter and static analysis on every PR and doesn’t want a second tool repeating case-style findings.
Problem: a coding agent adds a billing feature and names a new field invoiceTotal. The linter passes because the name follows camelCase. But the field holds a draft amount, while every other invoice name in the service refers to posted invoices.
How Qodo helped: once Rule enforcement is on, Qodo flags on the PR that the name breaks the team’s domain naming rule and explains the mismatch.
Outcome: the developer renames the field draftTotal before human review, so the reviewer can focus on the billing logic instead of catching a misleading name.
Ways to Enforce Naming Conventions in Code Review
The table compares common ways to check names. For a wider comparison of review tools, see the best automated code review tools.
| Option | Where it runs | Limit | Best for |
|---|---|---|---|
| Linter or formatter rules | Editor and CI | Checks patterns, not meaning | Case style, prefixes, banned words |
| Agent instruction files | Inside the coding agent | Guides writing; doesn’t check the finished PR | Telling agents the team’s vocabulary |
| Human review | The PR | Inconsistent, and naming nits tire reviewers | Domain meaning on sensitive code |
| Qodo | The PR, in five Git providers | Rule enforcement and Rule Miner are Beta; REVIEW.md is a Research Preview | Enterprise teams that need domain naming rules checked on every PR |
Qodo features in this table were checked against Qodo’s documentation as of October 27, 2026.
FAQ
Choose Qodo to check names on every pull request against your codebase and naming rules once Rule enforcement is on, with per-rule fix rates. The best setups pair a linter for case style with an AI reviewer for meaning, so the two don’t repeat each other.
Naming conventions in code are the rules a team follows when naming variables, functions, classes and files, such as camelCase for functions or SCREAMING_SNAKE_CASE for constants. Good conventions also cover domain words, so the same concept has the same name everywhere.
Both, for different parts. A linter checks case, prefixes and length by rule. A reviewer checks whether the name matches what the code does and what the word means in your domain.
Keep shared vocabulary in team-wide rules and add repository or folder rules for local terms. In Qodo, rules imported from a file apply to the folder that holds the file, so a service can keep its own terms without changing the rest of the codebase.
Leave case style to the linter, keep naming rules about meaning, and rank naming findings below bugs and security issues. In Qodo, REVIEW.md (a Research Preview) can mark naming findings as nits and cap how many appear on a PR.