In Go's encoding/csv, what does Reader.FieldsPerRecord do at 0, at a positive value, and at -1?

## What the field counts `csv.Reader` returns each row as a `[]string` of parsed fields. `FieldsPerRecord` decides whether the reader polices how many fields each row has, and it is one of the few Go struct fields where the zero value is not the permissive option. Three modes, decided by sign: | Value | Behaviour | |---|---| | `0` (the zero value) | The number of fields in the **first record read** is recorded, and every subsequent record must match it. | | `> 0` | Every record must have exactly that many fields, including the first. | | `< 0` (idiomatically `-1`) | No check at all. Records may have any length. | ## The 0 case is the one people get wrong Because `0` is what you get by default, most Go programs read CSV with the check on without ever having asked for it. That is usually what you want — a column count that changes mid-file almost always means the file is broken — but it explains a class of bug reports that read "the import worked yesterday and today it fails at line 40,000". Nothing changed in your code; the partner appended a trailing summary line with three fields instead of seven. Note that the count is taken from the first record *read*, not from a header conceptually. If you consume the header with its own `Read` call, that header sets the count. If the header has a stray trailing comma and the data rows do not, every data row then fails. Also note what counts as a field: the reader has already handled quoting, so a quoted field containing commas is one field. The count is of parsed fields, never of comma characters on the line. Blank lines are skipped rather than treated as one-empty-field records, and lines beginning with the `Comment` rune, if you set one, are skipped too — neither participates in the count. ## The error you get A mismatch produces a `*csv.ParseError` whose `Err` is the sentinel `csv.ErrFieldCount` ("wrong number of fields"). Because `*csv.ParseError` implements `Unwrap`, both of the standard error helpers work: ```go if errors.Is(err, csv.ErrFieldCount) { /* ragged record */ } var pe *csv.ParseError if errors.As(err, &pe) { /* pe.StartLine, pe.Line */ } ``` `StartLine` is the line where the record began — which differs from `Line` when a quoted field spans multiple lines — and that is the number worth showing a human, because it is the row they will look for in the file. With `ReadAll`, a single ragged record aborts the whole call and you get no records back. With `Read`, the failure concerns one record and you can log it and keep going. ## When to set what **Leave it at 0** for a file you expect to be internally consistent and where you have no independent schema. It costs nothing and catches truncation and stray delimiters early. **Set a positive count** when you do have a schema and want the check applied to the first record as well. `r.FieldsPerRecord = 7` turns "the partner shipped last quarter's six-column format" into an immediate error on row one, instead of an import that succeeds and writes nonsense into the wrong columns. **Set -1** when the format is genuinely ragged by design, or when you want to own the validation so you can produce a better message than the package's. The moment you set -1 you have taken on the check: `if len(rec) != 7 { … }` inside the loop, with your own error carrying the line number, is the replacement. ## The trap worth naming The most common mistake is reading `FieldsPerRecord = 0` as "disabled" and then being astonished that an unchecked import fails on a ragged row. The second most common is setting `-1` to make an error go away without adding a replacement check — the rows still get imported, they are just wrong now, and the failure has moved from the parser to whatever downstream code indexes `rec[5]` and panics or, worse, silently reads the wrong column.