Programmers generally detest to do documentation, so when the user help "UI" is all down to a programmer to define this is often what you get, especially if it's a small tool.
Yeah this is shitty, and if you're a programmer reading this and you agree with it, be better. There is no excuse for under-documenting a CLI.
Even when I'm developing, I write out my usage text first, like -o [json,csv,pretty] specify output format (default 'pretty') [NOT IMPLEMENTED] or the like.
Speaking for myself a long time ago when I was younger and handsomer but dumber ;) some people at a certain stage of their lives have trouble remembering that what's obvious for oneself given the context one is in and the information one has, is not obvious for others.
Oh, you sweet summer child, there is no level of ease for the average programmer that will make him or her want to document things… ;)
On a more serious note, good documentation for parameters in any tool that's not stupidly simple tends to be more than a one liner if one doesn't assume that the user already knows a ton of context (for example, imagine explaining "chmod" parameters with just one liners)
You can write more than one line but one line is usually enough for each of the options in the --help output. Obviously that doesn't explain everything and especially not background like "how do unix permissions work" in your example but the --help output is not the correct place for that kind of information anyway.
The point is that a programmer would first need to think about what needs to be explained or not to the average user and then explain it properly, none of which is considered as interesting as coding.
It's not by chance that even tools with actual one line of explanation for each parameter are general of the badly documented kind (I especially like the ones were the "help" for a command doesn't say what the bloody command actually does).
I mean, you even see this kind of meaningless "documentation" in API documentation for widelly used libraries were the documentations is generated from comments embedded in the code: "public void doStuff(int height)" => "Does stuff. Parameters - height: the input height".
I might have put it in a humouristic way but this quite a well-known and widespread phenomenon.
Programmers generally detest to do documentation, so when the user help "UI" is all down to a programmer to define this is often what you get, especially if it's a small tool.
I never understood that. I'm a programmer and I tend to over-document.
the messiah
Yeah this is shitty, and if you're a programmer reading this and you agree with it, be better. There is no excuse for under-documenting a CLI.
Even when I'm developing, I write out my usage text first, like
-o [json,csv,pretty] specify output format (default 'pretty') [NOT IMPLEMENTED]or the like.Speaking for myself a long time ago when I was younger and handsomer but dumber ;) some people at a certain stage of their lives have trouble remembering that what's obvious for oneself given the context one is in and the information one has, is not obvious for others.
I like to think most of us grow out of it.
Morgan Freeman: "But they didn't"
If you use something like Rust's clap --help output is very easy to add, all you need is basically a single line comment for each option.
Oh, you sweet summer child, there is no level of ease for the average programmer that will make him or her want to document things… ;)
On a more serious note, good documentation for parameters in any tool that's not stupidly simple tends to be more than a one liner if one doesn't assume that the user already knows a ton of context (for example, imagine explaining "chmod" parameters with just one liners)
You can write more than one line but one line is usually enough for each of the options in the --help output. Obviously that doesn't explain everything and especially not background like "how do unix permissions work" in your example but the --help output is not the correct place for that kind of information anyway.
The point is that a programmer would first need to think about what needs to be explained or not to the average user and then explain it properly, none of which is considered as interesting as coding.
It's not by chance that even tools with actual one line of explanation for each parameter are general of the badly documented kind (I especially like the ones were the "help" for a command doesn't say what the bloody command actually does).
I mean, you even see this kind of meaningless "documentation" in API documentation for widelly used libraries were the documentations is generated from comments embedded in the code: "public void doStuff(int height)" => "Does stuff. Parameters - height: the input height".
I might have put it in a humouristic way but this quite a well-known and widespread phenomenon.
No idea why'd anyone would do this if they expected anyone besides them to use their tool.
Even I myself am not gonna remember how to use my tool a couple months down the line, unless it's something I use very regularly.
Edit: noticed I read the comment I'm replying to wrong, reworded to make more sense