Why does Go write a multi-word identifier as maxRetryCount rather than max_retry_count?

## The rule Go writes multi-word identifiers in **MixedCaps** (also called CamelCase): every word after the first begins with a capital letter, and the words are simply run together with nothing between them. `maxRetryCount`, `parseRequestBody`, `DeadLetterQueue`, `serveIndex`. The exported form starts with a capital (`MaxRetryCount`), the unexported form with a lowercase letter (`maxRetryCount`) — but in both, the *joining* of words is done with case, never with an underscore. This applies to every kind of name you declare: local variables, parameters, struct fields, methods, functions, types, constants and package-level variables. It also applies to constants, which is worth calling out because engineers arriving from C, Java or Python often expect `MAX_RETRY_COUNT`. Go does not use SCREAMING_SNAKE_CASE for constants at all. A constant is named exactly like any other identifier: `MaxRetryCount` if it is exported, `maxRetryCount` if it is not. There is no visual marker distinguishing a constant from a variable in Go, and none is wanted. ## Why case rather than underscores The usual answer is "because that is the convention", and for a junior interview that is nearly enough. But there is a structural reason worth being able to give. In Go, the case of a name's first letter is not a style choice — it is part of the language. A name beginning with an uppercase letter is visible to other packages; a name beginning with a lowercase letter is not. That means every Go engineer is already reading the case of identifiers for meaning, on every line, all day. Once case carries information, using it as the word separator too is cheap: the reader is already looking at it. Adding underscores on top would produce names like `Max_Retry_Count`, where the reader has to parse two separators that mean different things. The secondary reason is length. Go's culture favours short names, especially in short scopes. Underscores make names longer without making them clearer. ## What the toolchain does and does not do This is the part candidates most often get wrong. `gofmt` is not a linter and not a renamer. It normalises whitespace, indentation, alignment, the placement of braces and the grouping of imports. It will happily format a file full of `user_id` fields and change nothing about them. `go vet` reports likely bugs — a `Printf` verb that does not match its argument, a lock copied by value, an unreachable return — and says nothing about identifier casing. So MixedCaps is enforced by **people**: code review, and the fact that the standard library is written that way and every Go engineer has read it. If your team wants machine enforcement, that is a linter question, not a toolchain one. In an interview, saying "gofmt will fix it" is a concrete factual error and a bad look, because it suggests you have never actually watched gofmt run on a badly named file. ## Where underscores legitimately live Underscores are not banned from Go source — they are banned from *identifiers you declare*. They appear in: - **File names.** `user_service.go`, `user_service_test.go`, and the build-constrained suffixes the `go` command understands, such as `poll_linux.go` or `asm_arm64.s`. The `_test.go` suffix and the `_GOOS`/`_GOARCH` suffixes are part of the toolchain's own naming grammar. - **The blank identifier `_`**, used to discard a value (`_, err := f()`), to import a package purely for its side effects, or to assert at compile time that a type satisfies an interface (`var _ io.Reader = (*myReader)(nil)`). - **Generated and machine-derived code**, where names sometimes mirror an external system (C symbols reached through cgo, for example). This is tolerated precisely because a human did not choose the name. ## Where the mistake usually comes from The recurring source is a name imported from somewhere else: a database column `created_at`, a JSON key `user_id`, an environment variable `MAX_RETRIES`. The Go answer is that the *external* name stays in its own spelling — in a struct tag, in a query, in an `os.Getenv` call — and the Go identifier is spelled the Go way. So a struct field is `CreatedAt time.Time` with a tag mapping it to the external `created_at`; it is never a field named `Created_At`. The second source is a script or generator emitting Go from another system's names. That is the same problem at scale, and the fix is the same: canonicalise the name into Go's spelling at the boundary, once, in the generator. ## What an interviewer is checking That you have internalised the convention rather than memorised it, that you know case is semantically load-bearing in Go, and that you do not believe a formatter will rescue you. A candidate who says "MixedCaps, no underscores, and note that constants follow the same rule — there is no `MAX_SIZE` in idiomatic Go" has answered fully in two sentences.