For a language so focused on “safety” in all aspects, we sure have a lot of ways to get the clap!
I want to note that
ClapMe almost always produces long flags. This is because I feel that long flags are generally the easiest to use.
I really like this idea, just do one sensible default, without too much woods to get lost in; after all, the programmer has bigger things to worry about than the best short-form of his command-line option.
When doing my own scripting, I also usually go for the long-form, as they are far more self-documenting. I am always annoyed when I open something from a colleague, and I first spend two minutes deciphering "sometool -aGrTnFf input-file’
Future-me thanks you for reducing the possibilities for crypticness!
Comparing this wider: I find it interesting to see the many different trade-offs the community is experimenting with: One the one end of the spectrum: low-level and custom attributes to define every niggly little detail, help text and handling-logic, and on the other end high-level “does-what-you-mean” like ClapMe here.
I’m curious how that spectrum will end up being used in practice!
We add help information simply by adding ordinary doc comments to our struct.
In most of this documentation I’ll avoid adding help text, just to keep the page short, but I would always add it for actual projects!
Since your guide is the primary example of best-practices (and probably copy-paste coding too ), I’d advise differently; include at least a minimum one-liner in all cases to set the proper precedent!
Flattened nesting types
This idea is just inspired
I really like that this creates the option to keep different concerns (e.g. log levels vs. algorithm parameters) separated at the code-level, while still presenting a unified interface.