a common mistake when using Strconv Package
Fast recall
Quick revision
Core answer
Practical understanding of Strconv Package.
Repeating a definition without saying when to use it.
Give one trade-off and say how you would test it.
Interview-ready guide
Interview answer
ParseBool accepts the short forms:
b, err := strconv.ParseBool("true") // true, nil
b, err := strconv.ParseBool("1") // true, nil
b, err := strconv.ParseBool("T") // true, nil
b, err := strconv.ParseBool("yes") // false, error — not in the setThe truthy set: "1", "t", "T", "true", "TRUE", "True". The falsy set: "0", "f", "F", "false", "FALSE", "False". Anything else is an error.
Why this particular set: it matches strconv's own FormatBool round-trip and the common single-letter conventions (t/f) from config-file formats and CLIs. The set is fixed — you can't extend it.
For OTHER truthy vocabularies ("yes"/"no", "on"/"off", "y"/"n"), ParseBool doesn't help — that's a map lookup or a switch you write:
var truths = map[string]bool{"yes": true, "on": true, "y": true}The design note: Go puts the strict, mechanical parse in the stdlib and leaves the human-vocabulary handling to the app — consistent with strconv's everywhere-explicit philosophy.
a common mistake when using Strconv Package
Direct Answer
strconv.ParseBool: accepts "1", "t", "T", "true", "TRUE", "True" (and the falsy set) — case variations of the truthy words. NOT just "true"/"false" — the wider set comes from strconv's own conventions.
Deep Dive & Architecture
The round-trip contract as the design driver: FormatBool(b) produces 'true'/'false' (lowercase only), and ParseBool accepts those — plus the wider short forms. The asymmetry (format is narrow, parse is wide) is the deliberate pattern: produce canonical output, accept liberal input — Postel's law applied at the function level. The same pattern appears in ParseInt (accepts prefixes) and time parsing (RFC3339 strict, but the layout system is liberal in what layouts exist).
The error shape: ParseBool's error is a *NumError carrying (Func: "ParseBool", Num: input, Err: ErrSyntax) — the strconv error type across the family. The structured error lets callers distinguish 'bad syntax' from 'out of range' (ParseInt family) — for ParseBool, syntax is the only failure. errors.Is(err, strconv.ErrSyntax) is the idiomatic branch — the sentinel pattern the errors topic covered, appearing inside strconv's small API.
Where ParseBool appears in the wild: encoding/json's own boolean parsing converges to the same true/false set; CL flag parsing (flag package) uses its own narrower set; config libraries (viper, yaml) implement the wider yes/no/on/off maps on top. Knowing ParseBool's fixed vocabulary answers 'why does my yes/no config fail to parse' — the stdlib's answer is strict; the human vocabulary is your layer.
Common Mistakes & Pitfalls
Repeating a definition without saying when to use it.
Check your understanding
Answer these without looking back at the article.
- What is Strconv Package, and when would you use it?
- When would you use Strconv Package in a real project?
- How would you compare Strconv Package with an alternative?
Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.