Why do naked returns in a long Go function with named results make bugs easy to miss?

## What a bare return actually promises When every result in a signature is named, Go permits `return` with no operands. It returns the current values of the named result variables. That is the whole rule, and it is the source of both the convenience and the hazard: **the statement's meaning depends entirely on state established elsewhere**, and the statement itself contains no evidence of what that state is. Contrast the two exits: ```go return problems, ok // this line tells you what the caller gets return // this line tells you nothing ``` Both compile, both are idiomatic Go, and in a six-line function they are equally readable because the entire body is visible at once. The difference only appears with distance. ## The three ways distance turns it into a defect **1. The names are far away.** A reader looking at the bare `return` on line 180 has to jump back to the signature to learn there even *are* two results, let alone what they are called and what they mean. Reading code is mostly local; a construct whose meaning is defined 180 lines up is a construct that forces non-local reading. **2. A skipped assignment returns a zero value nobody chose.** Every named result starts at its type's zero value and stays there until something assigns it. An early exit added months later — a guard clause, a fast path, a check for an unreadable file — bares-returns before the assignments run, and the caller receives `nil`, `0`, `false` or `""`. Consider a config validator invoked from a CI step: ```go func validate(path string) (problems []string, ok bool) { data, err := os.ReadFile(path) if err != nil { return // (nil, false): "invalid", with nothing to show } problems = checkAll(data) ok = len(problems) == 0 return } ``` The early exit is *shaped* like the happy path's exit, so a reviewer's eye slides over it. The build turns red, the step prints "config invalid", the list of problems is empty, and the engineer on the pull request cannot tell an unreadable file from a file full of mistakes. The information was available at the failing line and the return statement discarded it — the same silent-failure pattern as dropping a result with `_`, arrived at from a different direction. **3. Nothing mechanical catches it.** `gofmt` reformats it happily. The compiler is satisfied — the function returns two values of the right types on every path. Vet's standard analyzers have nothing to say about a legal return of a zero value, because a zero value is frequently the correct answer. The only line of defence is a human reading the diff, which is precisely why teams turn it into a review convention rather than hoping. ## What the convention should be The widely-held Go position is not "never name results" or "never bare-return" — it is that the two decisions are independent and should be made separately: - **Name results for documentation.** `strings.Cut(s, sep string) (before, after string, found bool)` and `io.Reader`'s `Read(p []byte) (n int, err error)` name their results so the signature explains itself. That reason applies regardless of how you return. - **Bare-return only in a function you can take in at a glance** — a handful of lines, one or two exits, all assignments visible above the return. Below that bar, write the values out. - **Never mix the forms in one function.** A body with `return a, b` in three places and a bare `return` in a fourth invites the reader to assume the fourth is the same as the others. - **Prefer shortening the function.** A 200-line function whose exits are hard to follow has a bigger problem than its return statements; extracting the branches usually makes both issues disappear at once. ## Reviewing it in practice When a bare return shows up in a pull request, the useful questions are: how far is this line from the signature, is every named result assigned on every path that reaches here, and would an explicit return read worse? The last one matters — occasionally the explicit form is genuinely noisier, in a tiny helper with three results that are all set on the line above. That case is real and rare, and it is the case the convention should permit rather than the default it should assume. The deeper point is about where the information lives. Go's design consistently prefers statements that state what they do: a `return` with operands is one of them, and a bare `return` trades that away for a few saved characters. In small functions the trade is free. In large ones you are paying for it with every subsequent read.