[Design] Kebab case vs. Snake case

[neoniobium]

Case Convention for Options, Parsers, and Arguments

Details

Currently, cmd2 uses kebab case (hyphen-separated words, e.g. --kebab-case) for parameter arguments (for example --separated-words) and snake case (underscore-separated words, e.g. snake_case) for options such as the built-in settables, the built-in parsers run_script and run_pyscript, and for the (sub)parser names generated by with_annotated. There might be a few other cases as well.

While I can’t point to any general standard for CLI apps, this choice seems quite unconventional to me. I’m not aware of any widely used applications—such as git, docker, or GNU utilities—that use underscores for word separation. For example, Typer appears to automatically convert underscores to hyphens in at least some cases.

For parameter names (see #1666), such auto conversion is already happening.

In particular, the snake-case parser naming convention feels odd to me. Moreover, I find kebab case more ergonomic since it doesn’t require the user to press Shift while typing commands.

Possible solution (if any)

I’m not insisting on any changes. However, I wanted to flag this in case it isn’t a deliberate design decision, but instead a downstream result of Python’s function and variable naming conventions.

Reference

This issue #907 discusses something quite similar.

[KelvinChung2000]

For the annotated case, I just converted all the snake case to kebab case. Because I simply think --option_a does not look nice, and --option-a is the much preferred/common option. It is possible to override it like dry_run: Annotated[bool, Option("--dry_run")], just to make sure any form of naming is supported.

The situation with the subparser and the snake-case leak is that I did not consider that this could happen during implementation. Since I will want to auto-convert all to kebab case as well.