this post was submitted on 21 Jun 2023
57 points (100.0% liked)

Programming

17432 readers
233 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Rules

  • Follow the programming.dev instance rules
  • Keep content related to programming in some way
  • If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities !webdev@programming.dev



founded 1 year ago
MODERATORS
 

The mistake most devs make when trying to document their project is that they only make one (maybe two) types of documentation based on a readme template and/or what their mental model of a newcomer needs.

Devs need to be actively taught that:

  1. Good documentation isn't one thing, it's four. To have good documentation, you need all four distinct types of documentation.
  2. What the four types of documentation are (this is discussed in the link)

If you don't have all four types of documentation, you have bad documentation.

you are viewing a single comment's thread
view the rest of the comments
[–] torturedllama@lemmy.nz 1 points 1 year ago (1 children)

The issue I see a lot in the JS ecosystem is laying out documentation like a reference guide, but then not including all parameters or functions. These types of documentation are very helpful if what you need to know is included, because they have nice friendly explanations and examples. But eventually you will run into a parameter that is mentioned on Stack Overflow, or is in a code snippet in the documentation, but then has no further explanation in the documentation, as if it doesn't exist.

Projects where the README is the only documentation seem to suffer from this problem the most. They give examples of the most common parameters and functions, and then that's it.

In JS this is a big issue because there may be no way to know a parameter even exists, or what values it accepts, unless it is documented.

A lot of documentation in the Java ecosystem has huge auto-generated monstrosities with absolutely no explanations. In Java this is usually not useful because that information can be found in the types. But in JS it would be incredibly useful. Unfortunately it isn't as easy to automatically generate that type of documentation for JS.

Python in my experience has the best of both worlds. It has the friendly explanations and examples. But also has all of the parameters, even if explanations for some are a bit less detailed. And all of that is combined into a single place.

[–] spartanatreyu@programming.dev 2 points 1 year ago (1 children)

The good thing about the JS ecosystem is that almost everything in the last few years is written in typescript.

Just by typing in the name of the function and opening the first parenthesis, you're getting type information right there.

For example, typing:

globalTestSetup(

Presents a modal showing:

globalTestSetup(options: { page: Page, slow?: boolean, locale?: string } );
[–] torturedllama@lemmy.nz 2 points 1 year ago

Mm indeed. Types to the rescue.

Are there any projects/tools that turn the types into Java-style web html documentation? If you need to know something while you're working on a non-typescript project that could be more convenient.