Command line parsing
Jacob Carlborg via Digitalmars-d
digitalmars-d at puremagic.com
Thu May 12 23:44:11 PDT 2016
On 2016-05-02 14:52, Andrei Alexandrescu wrote:
> I found this in https://peter.bourgon.org/go-best-practices-2016/:
>
> "I said it in 2014 but I think it’s important enough to say again:
> define and parse your flags in func main. Only func main has the right
> to decide the flags that will be available to the user. If your library
> code wants to parameterize its behavior, those parameters should be part
> of type constructors. Moving configuration to package globals has the
> illusion of convenience, but it’s a false economy: doing so breaks code
> modularity, makes it more difficult for developers or future maintainers
> to understand dependency relationships, and makes writing independent,
> parallelizable tests much more difficult."
>
> This is interesting because it's what std.getopt does but the opposite
> of what GFLAGS (http://gflags.github.io/gflags/) does. GFLAGS allows any
> module in a project to define flags. I was thinking of adding
> GFLAGS-like capabilities to std.getopt but looks like there's no need
> to... thoughts?
I can see it being useful for a tool like git which has sub
commands/actions to parse the global flags in the main function and
parse the sub command specific flags in the module handling the sub command.
I've also built a library that does some of the boilerplate to setup a
tool/application that parsers generic flags (like "help" and "version")
and allows to add application specific flags as well.
--
/Jacob Carlborg
More information about the Digitalmars-d
mailing list