Field & Type Naming

## The specification's name grammar is short Every name in GraphQL — object and input type names, field names, argument names, directive names, enum value names, variable names, fragment names — comes from one lexical production. A name begins with a letter or an underscore and continues with letters, digits or underscores, which is usually written `/[_A-Za-z][_0-9A-Za-z]*/`. That is the whole syntax rule. No hyphens, no dots, no colons, no spaces, no leading digit, no punctuation of any kind. If you have ever tried to surface a column called `gross-pay-ytd` or a payload key called `401k.match` on a payroll graph as a field, this is the rule that stopped you, and the remedy is a mapping inside the server: GraphQL has no escaping or quoting syntax for names. ## Names are case-sensitive `grossPayYtd` and `grossPayYTD` are two different names, and a type may legally declare both. Nothing folds case anywhere in the language — not in the schema, not in a document's selection set, not when a response key is written out. This matters more than it sounds, because a schema assembled from several sources is exactly where you end up with `employeeId` on one type and `employeeID` on another, and the two are unrelated names that every consumer must remember separately. ## The one reserved prefix The specification reserves names beginning with two underscores for the introspection system, and it states this as a requirement on the type system rather than as advice. A conforming implementation rejects `type __Payslip` or a field named `__auditTrail` when it builds the schema — before any request is executed, not at query time. This is the only naming rule in the specification that has anything to do with meaning rather than characters, and it is the only one that can make a schema fail to build for a reason a reader would call semantic. A single leading underscore is legal: `_internalRef` builds fine. It reads as a near miss, and most reviewers will ask for it to go. ## Enum values carry two more real rules An enum value is written as a bare name, so the specification excludes the three names that already mean something in the input language: an enum value may not be `true`, `false` or `null`. Beyond that, the specification *recommends* — in one of the very few places it makes a stylistic recommendation at all — that enum values be written in all caps. A recommendation is not a rule. `enum PayFrequency { weekly biWeekly semiMonthly }` builds and executes; it simply looks wrong to every reader and to every generator's default identifier mapping. ## Everything else is habit camelCase for field and argument names, PascalCase for every named type, SCREAMING_SNAKE_CASE for enum values, and the `Input` suffix on input object types are ecosystem conventions with no specification backing whatsoever. The reason they are so uniform is that the specification follows them itself: its own introspection types, its built-in directives — `@skip`, `@include`, `@deprecated`, `@specifiedBy` — and their arguments `if` and `reason` are all written in exactly that style. Implementations copied the style of the document that defined them, and generated schemas copied the implementations. ## Why breaking a convention still costs you First, generated code. A typed client generator maps schema names onto identifiers in a target language, and each one has its own transformation rule. Give it `employee_id`, `employeeId` and `Employee_ID` as three fields on the same type and you can get mangled or colliding identifiers in the output, or an identifier that no longer resembles the field it came from. A name that is legal GraphQL is not automatically a distinct, legal identifier downstream. Second, readers. A schema is read far more often than it is written, and it is read in autocompletion lists and documentation panes where the only cue about what kind of thing a name is is its case. In a schema where types are PascalCase and fields camelCase, `Payslip` and `payslip` are instantly distinguishable as a type and a field. Break that and every reader has to slow down. Third, the cost of change. Field and type names are the contract: they appear in every document a client has shipped and, for types, in fragment type conditions. Fixing a name later is not a local edit, which is why the convention question is really a question about doing it once, correctly, at the start. ## What the interviewer is testing Two things that pull against each other. The first is that you can tell a rule from a habit: a candidate who says "the specification requires camelCase" has confused what a linter enforces with what the language enforces, and that same confusion tends to show up later as confident wrong claims about what is and is not specified elsewhere in GraphQL. The second is that you follow the habit anyway, without needing a rule to make you. The strong answer is the one that names the real constraints — grammar, case sensitivity, the reserved prefix, the three forbidden enum value names — and then says that everything else is convention that you enforce as if it were a rule.