+1 to referring to gflags with dashes instead of underscores in Kudu docs. But, I don't know whether gflags can be coerced to programmatically emit flags with dashes (i.e. when invoked with --help) without a patch or two. Certainly in the code we would want to retain the use of underscores when referring to flag variables; FLAGS_foo_bar conforms to our coding style more than something like FLAGS-foo-bar.
On Mon, Apr 10, 2017 at 11:00 AM, Alexey Serbin <[email protected]> wrote: > I think it's a good move. It would be nice to add a notice about that in > the user-facing docs. > > Also, I think it would be more consistent to convert those flags altogether > at some point to be in dash-ish form, both the code and the docs. Maybe, > 1.4 is a good point to do that. > > > Kind regards, > > Alexey > > > > On 4/10/17 10:42 AM, William Berkeley wrote: >> >> I agree, for the reason you gave: dashes are the norm in Unix, so they >> "feel right" for flag names. >> >> -Will >> >> On Mon, Apr 10, 2017 at 1:38 PM, Dan Burkert <[email protected]> >> wrote: >> >>> Hi all, >>> >>> As of Kudu 1.3, multi-word flags can use a dash '-' separator in lieu of >>> the underscore '_' separator. For example, --memory_limit_hard_bytes >>> can >>> now be specified as --memory-limit-hard-bytes, or even >>> --memory_limit-hard_bytes. Of the people I've talked to, most seem to >>> prefer dashes to underscores in flag names, since that's been the Unix >>> norm >>> for a long time. >>> >>> Going forward, I'd like to propose that we document flag names using >>> dashes >>> wherever possible. We would continue accepting underscores indefinitely, >>> since to stop doing so would break compatibility. For the most part, this >>> means incrementally switching the documentation to use dashes, and >>> getting >>> glog to output dashes in --help output. >>> >>> Any thoughts? >>> >>> - Dan >>> >
