• @Aceticon
    link
    32
    edit-2
    1 year ago

    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.

    • @[email protected]
      link
      fedilink
      161 year ago

      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.

    • @Aceticon
      link
      6
      edit-2
      1 year ago

      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.

      • @EuroNutellaMan
        link
        41 year ago

        I like to think most of us grow out of it.

        Morgan Freeman: “But they didn’t”

    • @[email protected]
      link
      fedilink
      51 year ago

      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.

      • @Aceticon
        link
        13
        edit-2
        1 year ago

        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)

        • @[email protected]
          link
          fedilink
          21 year ago

          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.

          • @Aceticon
            link
            2
            edit-2
            1 year ago

            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.

    • 👁️👄👁️
      link
      fedilink
      English
      31 year ago

      No idea why’d anyone would do this if they expected anyone besides them to use their tool.

      • @[email protected]
        link
        fedilink
        1
        edit-2
        1 year ago

        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