PromptDev

Write docstrings for code

Docstrings that carry behaviour, edge cases and side effects — every parameter line adds something the signature does not already say.

Last updated

Fill in the blanks

Assembled in your browser — nothing you type is stored or sent anywhere.

Your prompt

Write docstrings for the code below in JSDoc style. For each function or class, document: what it does (behaviour, not implementation), the edge cases and error conditions it handles or explicitly doesn't, and any non-obvious side effect. Do not write a docstring that just restates the parameter names as prose — every parameter line must add information the signature doesn't already give: units, valid ranges, what an empty or null value means, or what happens if it's wrong. Skip any function that's already self-explanatory instead of padding it with a docstring that adds nothing. If a function's behaviour is ambiguous from the code alone, say what's unclear rather than guessing. Code: [paste the module or file here]

Model-agnostic — works in Claude, ChatGPT, Gemini or any AI chat.

Why this prompt works

  • →Banning parameter-restating docstrings targets the default LLM failure directly: verbose, technically complete docstrings that add zero information over the function signature.
  • →Asking specifically for edge cases and error conditions gets the part of a docstring that's genuinely hard to infer from a casual read — what happens at the boundaries.
  • →Permission to skip self-explanatory functions keeps the output honest — blanket docstring coverage otherwise turns into noise that buries the functions that actually needed it.

Part by part

what it does (behaviour, not implementation)
The distinction that separates a useful docstring from a paraphrase of the body. Implementation changes; documented behaviour is a contract.
the edge cases and error conditions it handles or explicitly doesn't
Asks for the negative space, which is what callers actually need and what reading the signature cannot give them.
every parameter line must add information the signature doesn't already give
The rule that prevents the most common failure — restating parameter names as prose. Units, ranges and null meaning are the useful additions.
Skip any function that's already self-explanatory
Explicit permission to write nothing. Without it a model documents every getter, which adds noise and buries the docstrings that matter.

Common mistakes

  • Add docstrings to this code.

    Produces a docstring per function that restates the name and lists the parameters, including trivial ones. The output looks like documentation and tells a reader nothing they could not see.

  • Document this code thoroughly.

    Thorough is read as more words, so every function gets a paragraph and the important caveats are diluted. Specifying what each line must add is what constrains the volume.

  • Explain what this code does.

    Asks for a description of the implementation, which becomes wrong the moment the implementation changes. A docstring should describe the contract, not the current mechanism.

Questions

Why forbid restating the parameters?

Because it is the default output and it is worthless — a reader already has the signature. Units, valid ranges, what an empty value means and what happens when it is wrong are the things the signature cannot express.

Should every function have one?

No, and the prompt says so explicitly. A docstring on a self-explanatory function is noise that trains readers to skip docstrings, which then hides the ones carrying real caveats.

Which style should I pick?

Whichever your tooling parses — Google or NumPy for Python, JSDoc for JavaScript, and whatever your linter already enforces. Consistency matters more than the merits of any format.

Can it document behaviour it cannot see?

No, and the prompt tells it to flag ambiguity rather than guess. A function whose behaviour depends on global state or an external service will be documented incompletely unless you supply that context.

Related in Prompts