We have a command-line option module that inspects the tool’s embedded POD, which is specially formatted to be both human-readable and machine-readable. There’s a lot of deep magick in it, but I can summarize it. The –help output comes from the OPTIONS section of POD; so does the internal access to the options passed on the command line. Default values and a lot of validation rules are worked into the POD too, in various places. We also have magical bits of text that the tools use, e.g. when the POD says “the default create-table statement looks like this…” then the tool grabs that following paragraph and uses it. Or the POD says “at least one of –foo or –bar is required” — the module enforces that.

It’s a little exaggerated to say there is no mismatch between behavior and documentation, actually. What I mean is, if the POD documentation says there is a –foo option and that it’s required and it negates the –bar option, then it does. The tool’s behavior and functionality is probably a superset of the documentation, and of course there could be prose that’s wrong. But the steps we’ve taken do go a long ways towards keeping docs and behavior in sync!

So rather than “no mismatch” I might instead say “no duplication” or something like that.