search

gnolang / gno

Gno: An interpreted, stack-based Go virtual machine to build succinct and composable apps + Gno.land: a blockchain for timeless code and fair open-source
https://gno.land/
Other
839 stars 342 forks source link

RFC(philosophy): Limiting depth of commands and subcommands in CLIs #2336

Open moul opened 2 weeks ago

moul commented 2 weeks ago

The current CLIs has multiple levels of depth for commands and subcommands, which can be confusing for users IMO.

I propose limiting the depth of commands and subcommands. For example, we could switch from gnoland genesis txs add sheets to gnoland genesis txs-add-sheets. This would make the CLI more user-friendly, as the first -h command would display top-level commands and subcommands ecosystems, and the -h of a subsystem would provide the full list of potential options, ideally sorted alphabetically.

grepsuzette commented 1 week ago

For example, we could switch from gnoland genesis txs add sheets to gnoland genesis txs-add-sheets

Only when it makes sense, but I would disagree this should constitute a philosophy.

To make up an example, if we had mycommand scripts maintenance certificates check_validity, it would be deep, but if the depth was proportionate to the rarity with which it was typed, or if the depth allowed the local tree of subcommands to be well-balanced, it would not only be fine but arguably better to a shorter command such as mycommand scripts certificates-check-validity.

Of course there are a lot of cases where limiting depth is not only acceptable but superior.