Naming Things: Prompt Options for Variables & Functions

A logistics route-planning service had a function called processData(), three module-level variables named d, m, and x, and a return object whose keys were a, b, and c. A new engineer spent most of a day tracing which variable held the distance matrix, which held the depot list, and which held the delivery time windows, because nothing in the code said so. The naming bill arrives months later, when the original author has forgotten the intent and every change feels risky. Naming is a prompt decision, and you can be specific about which style you want before you ask the model to write a line.

This guide compares four naming styles you can request from ChatGPT, with a decision table, the moment each fits, a copy-paste prompt for each, and the cost you take on. Every example lives inside one service: a logistics route-planning backend that turns a list of stops into an ordered delivery route. To decide how much structure to fix in the prompt versus leave to the model, see code versus architecture prompting. When you want the model to read an unfamiliar module and rename consistently, the approach in explaining a codebase to ChatGPT pairs well with the prompts below.

Naming Style Comparison

Two questions pick the style. First, how long will this name live: a throwaway script or a function other teams will import? Second, who reads it next: the author tomorrow, or a stranger in six months? Short-lived code tolerates compact names. Shared code does not. When the two answers conflict, favor the reader who has not seen the file before.

Picking a Style by Lifespan

Verb-phrase descriptive for anything shared. A function that other modules call should say what it does, not what it is. buildDistanceMatrix, orderStopsByTimeWindow, and validateDepotCapacity read as sentences, which means a reviewer can check behavior from the call site alone. The failure mode is padding: computeTotalDistanceForRoute is accurate and exhausting, and getDistance wins once the parameter names carry the rest.

Domain-noun compact for the inside of one file. Within a routing module, depot, leg, and timeWindow are precise because the vocabulary is defined in the domain. These names stay short and read like the problem description. The trap is exporting them: a bare leg means nothing in a billing service, so keep domain jargon local and give cross-module values a longer, self-contained name.

Type-encoded when values look alike. When a function juggles a distance matrix, a stop list, and a time-window list that all happen to be arrays, a type hint in the name prevents a whole class of bug. stopIds, matrixFloat64, and windowsSeconds tell a reader not just the meaning but the shape. Use it sparingly; encoding a type that is already obvious, such as userNameString, is noise.

Convention-matched inside a large codebase. When a repository already uses a pattern, matching it beats inventing a cleaner one, because consistency is what lets engineers read unfamiliar files fast. Ask the model to inspect the surrounding code and follow its conventions before it renames anything. Only break the pattern when the pattern is actively causing bugs, and then change it everywhere in one deliberate pass.

Copy-Ready Naming Prompts

Rename a messy function

Rename the function and its local variables in the code below so a reader understands intent from the signature alone.
Context: a logistics route-planning service.
Rules:
- Function name must be a verb phrase, for example buildDistanceMatrix or orderStopsByTimeWindow.
- Parameters and locals must use domain terms from the surrounding module, not single letters.
- Do not change behavior, signatures beyond the rename, or formatting outside the renamed lines.
- For each rename, give the old name, the new name, and a one-line reason.
- If a name cannot be improved, say "keep" and explain why.
Code:
[PASTE CODE]

Build a domain glossary first

Read the logistics routing code below and extract a glossary of the domain terms it uses, such as depot, leg, time window, and capacity.
For each term give: the term, a one-sentence definition in this code's sense, and its current identifier in the code.
Rules:
- Flag any term used with two different meanings.
- Flag any identifier that does not match a glossary term.
- Do not rename anything yet; output the glossary and the flags only.
- Keep the glossary under 15 terms.
Code:
[PASTE CODE]

Add type cues to similar values

In the code below, several variables hold arrays of different meaning. Propose names that encode the value's shape only where it removes real ambiguity.
Rules:
- Prefer stopIds over ids, matrixFloat64 over matrix, windowsSeconds over windows.
- Do not encode a type that is already obvious from the value or the immediate context.
- List each proposal as old name, new name, and the bug it prevents.
- Leave names that are already clear unchanged and say so.
Code:
[PASTE CODE]

Match the existing convention

The snippet below is a new function for an existing logistics routing codebase. Before rewriting names, infer the naming convention used by the surrounding code.
Steps:
1. State the observed convention for functions, classes, constants, and booleans.
2. Rename the new function's identifiers to match it.
3. List every change and the rule it follows.
4. Call out any place where the existing convention is genuinely ambiguous, but do not fix it here.
Code sample from the existing codebase:
[PASTE 20 TO 30 LINES]
New function:
[PASTE CODE]

Where Each Style Breaks

Descriptive names fail through length. Once a name runs past roughly four words, call sites wrap and readers start skimming the middle, so the extra precision stops paying. Trim by moving detail into parameter names or a docstring rather than into an ever-longer function name. Compact names fail through assumption: they are only clear to someone who already holds the domain vocabulary, which is exactly the person who does not need help. Type-encoded names fail through decay, because when a value’s type changes the name silently lies.

Convention-matched names fail when the convention is invisible. If the team cannot state its own rule in one sentence, the model will guess, and two files will drift apart. Write the rule down, hand it to the model, and let it apply the rule rather than eyeball the existing code. Whichever style you choose, keep it consistent within a module; mixed styles cost more attention than any single style costs on its own.

One practical habit makes all of this cheaper. Ask for the rename as a separate step from the feature work, and ask for a reason per change, so reviewing names becomes a two-minute pass instead of a rewrite. Then run the test suite unchanged: if a pure rename breaks anything, the problem is a hidden dependency the names were concealing, and you have just found it on purpose instead of at runtime.

Sources & Notes

Prompts tested with ChatGPT on the GPT-4o and GPT-4.1 models in October 2026; the naming guidance is language-neutral and applies to TypeScript, Python, Go, and Java. The logistics route-planning service, its functions, and its variables are an illustrative scenario, not a real codebase. Convention examples reflect widely used community style guides rather than any single project. All prompts are copy-paste text; no external services were called. Category mapping follows the guunn.com AI Prompts plan (Coding = 957).