> Only func main has the right to decide the flags that will be available to the user.
This one applies to every language. I was working with a python package that decided that, since `sys.argv` was available from anywhere, it should parse `sys.argv` to configure its own behavior. For a long time, their suggestion was to first parse `sys.argv` yourself, then to modify it before going into the library.
Reminds me of when systemd parsed the kernel command line for the kernel debug parameter, making life hell for kernel devs.
It was so ridiculous, someone ended up sending in a patch for the kernel to modify the command line once it had been parsed to remove the debug parameter.
I agree but find it bizarre that this tip comes in a list of best practices for the major language invented at Google, when the same company's "gflags" library, also heavily used, advertises right at the top that it allows definition of flags in any source file!
https://gflags.github.io/gflags/
This defeats the purpose of a good flags library though.
Where flags shine is when you've some obscure tunable deep in the dependency tree that you need to tweak (particularly in an emergency). Plumbing through potentially thousands of flags through to main is nonsensical in that scenario.
Which works great, until you want to modify that parameter on the fly, or adjust it based on the current load of the system. Then you're sink, because you had that tunable parameter read from some global state, instead of being set from its parent.
No, the flags libraries I've used had exactly that issue.
When that came up what you'd do then is refactor that to be a class parameter or config option or whatever (and we'd usually ask that the flag be kept in some form).
Until then though you get the benefits of a quick and easy way to both expose and use tunables, which is much better than not having it at all.
This one applies to every language. I was working with a python package that decided that, since `sys.argv` was available from anywhere, it should parse `sys.argv` to configure its own behavior. For a long time, their suggestion was to first parse `sys.argv` yourself, then to modify it before going into the library.