RDoc VS JSDoc

In addition to project documentation, you've included a lot of code comments. You could adopt a standardized format and use it to generate API documentation. RDoc and YARD are two options. If I were reviewing this code at work, I would probably ask you to remove comments that explain what, not why.

That turns out to be a pretty common use case for markdown. Github, for example, renders your README.md is part of a git repo's "home" page. It's also common to have tooling that parses specially formatted comments in your source code and produce a documentation bundle, usually as a web page (ex. RDoc, YARD, JSDoc, etc.).

I have an open (draft) documentation PR for RDoc over at GitHub (https://github.com/ruby/rdoc/pull/824) that has six unanswered questions. These are embedded in the committed text itself, and each is labelled as "Reviewers: ...."

If you want to document your whole code base you should check https://github.com/ruby/rdoc

I suspect the fix is to remove_unparseable, and the repository, like the CVE, just hasn't been updated yet.

RDoc We'll use this gem to document our TwitchTag.rb class.

I wholeheartedly agree. At most, I introduce JSDoc[1] to newer developers as standardising how parameters and whatnot are commented at least gets you better documentation and _some_ safety without adding any TS knowledge overhead.

[1] https://jsdoc.app/

This is where JSDoc comes to save the day.

The best way to do this, of course, is with JSDoc. But something I always found awkward about jsdoc is defining the object types in the same file. So, after a lot of reading, I found a way to combine JSDoc with declaration type files from Typescript. Let me give you an example:

There is a lot of specific symbols presented on the JSDOC specification that can be found here: https://jsdoc.app

JSDoc is a specification for the comment format in JavaScript. This specification allows developers to describe the structure of their code, data types, function parameters, and much more using special comments. These comments can then be transformed into documentation using appropriate tools.

Working with new features, frameworks, and tools, the experience of reading documentation is a critical part of it. I have been lucky to work with projects that feature really easy to read documentation such as USWDS and Bun, but I've also had the misfortune to work with pretty terrible documentation like JSDoc. The JSDoc documentation lacks a search field which makes searching for specific items an ordeal and also does not cover many hidden use cases. It provides less than the bare minimum for what it needs to do - a lot of the time I am forced to rely on external user documentation elsewhere to use JSDoc effectively. That was why I was drawn to the search field in particular in Docusaurus.

The Svelte team followed suit but motivated by the maintainer's developer experience as they migrated the project away from TypeScript in favor of plain JSDoc comments for type annotations instead.

Even more relevant, tools like Javadoc, JSDoc, Doxygen, etc. read comments in a specific format to generate documentation. These comments do not affect readability. On the contrary, Javadocs are great for explaining how to use these entities. Combined with tools like my dear Doctest, we even get guarantees of accuracy and correctness!

Document types with JSDoc annotations

📚 JSDoc for documentation and jsdoc-to-markdown to create docs as markdown files