Why it is written this way
When asking AI for naming suggestions, it usually returns a single name. While it might sound reasonable, it lacks the context of why it was chosen and what alternatives were considered, making it hard to align with team standards. Naming isn't about finding a single correct answer—it's about choosing what intent to emphasize. Without comparisons, making an informed choice is difficult.
Enforcing a Format via a structured table is the core of this prompt. The column "How it reads at first glance" forces the AI to focus on a reader's impression rather than the author's intent. The column "When it becomes awkward or misleading" weeds out names that work today but break as soon as the feature expands slightly (e.g., fetchUser when it starts reading from a cache).
Providing an Example prevents vague interpretations of "different angles." Without examples, the AI tends to generate nearly identical names like getX, getXData, and getXInfo. Demonstrating distinct naming directions sets a baseline for genuine variety.
Strict Constraints prevent two common pitfalls: without language conventions, Python code might get camelCase names like getUserList, and without banning abbreviations, lazy names like procMgr creep in. Constraining the AI to "only include behaviors explicitly described" is crucial—hallucinating unperformed actions like andSendEmail causes significant readability issues down the road.
Unfamiliar terms? See Aha AI: prompt, output-format
Compared with a bad example
What is a good function name for calculating the final cart total?
You will simply get calculateTotalPrice. While decent, the name fails to reveal that it filters out out-of-stock items or applies discount coupons. Without alternatives to compare, developers adopt it blindly, only to re-read the implementation months later wondering, "Why is the total different from the subtotal?"
Variations
When naming files or directory paths
I need to determine the file name and folder path for a new module in a {{target language}} project. Based on the description below, suggest 3 candidates and describe the folder structure each candidate assumes in one sentence. Highlight any risk of confusion with commonly used naming patterns.
""" {{job role description}} """
Use this when structuring code organization rather than standalone identifiers. Explaining assumed directory layouts helps evaluate alignment with project architecture.
When reviewing multiple names at once
Below is a list of {{target language}} identifiers from a single file. First, evaluate each name as "Keep | Refactor". For those marked "Refactor", provide 2 candidate names and the reasoning in a table. Finally, summarize any inconsistencies in naming patterns across the file.
""" {{job role description}} """
Ideal for bulk renaming during refactoring. Requiring a triage step prevents unnecessary changes to names that are already clear.
Model notes
Pasting a few commonly used names from your team's codebase helps the model generate candidates that match your existing conventions.
If you ask for new candidates without guidance, models tend to produce minor variations of previous suggestions. Instead, pick one direction you like and ask: "Give me five more variations focusing exclusively on this angle." Pasting 5–6 existing naming examples from your codebase helps match your team's conventions.
Related prompts
Last updated 2026-09-02 · Found a mistake? Let us know