Build Your Software Factory: Win an iPhone Duo, Mac Mini, or Switch 2

Join the Hackathon →

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.

StyleExampleTypical use
camelCaseorderTotalVariables and functions in JavaScript, Java and Swift
PascalCaseOrderServiceClasses, types and components
snake_caseorder_totalVariables and functions in Python and Ruby
SCREAMING_SNAKE_CASEMAX_RETRIESConstants
kebab-caseorder-total.cssFile 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? retryDelayMs says more than d or delay2.
  • Does it match the domain meaning? If invoice means a posted invoice elsewhere, a draft shouldn’t share the name.
  • Does it tell similar things apart? userId and accountId shouldn’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.

CheckLinter or formatterReviewer, human or AI
Case style and prefixesYes, by ruleOnly if the linter misses it
Banned words and length limitsYes, by ruleRarely needed
Name matches what the code doesNoYes
Same word, same meaning across the codebaseNoYes, with codebase context
Rename consistency across callersPartly, through refactoring toolsYes, 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.

OptionWhere it runsLimitBest for
Linter or formatter rulesEditor and CIChecks patterns, not meaningCase style, prefixes, banned words
Agent instruction filesInside the coding agentGuides writing; doesn’t check the finished PRTelling agents the team’s vocabulary
Human reviewThe PRInconsistent, and naming nits tire reviewersDomain meaning on sensitive code
QodoThe PR, in five Git providersRule enforcement and Rule Miner are Beta; REVIEW.md is a Research PreviewEnterprise 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.