• Aceticon@lemmy.world
    link
    fedilink
    arrow-up
    33
    arrow-down
    1
    ·
    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.

    • pomodoro_longbreak@sh.itjust.works
      link
      fedilink
      arrow-up
      16
      ·
      1 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@lemmy.world
      link
      fedilink
      arrow-up
      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.

    • taladar@sh.itjust.works
      link
      fedilink
      arrow-up
      5
      ·
      1 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@lemmy.world
        link
        fedilink
        arrow-up
        15
        arrow-down
        2
        ·
        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)

        • taladar@sh.itjust.works
          link
          fedilink
          arrow-up
          2
          ·
          1 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@lemmy.world
            link
            fedilink
            arrow-up
            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.

      • hikaru755@feddit.de
        link
        fedilink
        arrow-up
        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