Lectures

We’ll break down what actually arrives to a Go program as CLI arguments (a slice [] string), why manual parsing via os.Args quickly turns into a mini-language that’s painful to maintain (validation, errors, --, short forms, help), and where this leads: it’s logical to move to the standard package flag, which takes care of the “boring” part of parsing arguments and generating usage.

We will go through the flag package in Go: how to declare flags via flag.String/ flag.Int/ flag.Bool, why the flag.Parse() call is needed, why the API returns pointers ( * T), and how to get positional arguments after parsing via flag.Args(), flag.NArg(), flag.Arg(i). We will also discuss the -- terminator and common mistakes when writing a CLI.

We break down a basic (but working) CLI contract in Go: where the command “verb” is ( add/ list/ done), what to do with positional arguments (via flag.Args(), flag.NArg(), flag.Arg(i)), and what to do with flags ( -priority, -limit). Plus: why the standard flag.Parse() “doesn’t like” flags after the command, how to build a dispatcher with switch, how to validate input (including err != nil), and why you should remember the terminator --.

We go over the basic discipline of Go CLI programs: why “data” should be printed to stdout, while diagnostics and hints should go to stderr; how this relates to pipelines ( tool | other-tool) and redirection ( > file); and how to make a clean usage via flag.Usage + flag.PrintDefaults(), printing the help text to os.Stderr and the result to os.Stdout.

We break down a “human-friendly” architecture for a Go CLI app: we separate argument parsing ( parseArgs()) and validation ( validateConfig()) from business logic ( App) and output rendering (rendering to io.Writer). The result is a thin and boring main, a single error style via error, and discipline: results go to stdout, diagnostics go to stderr.