chore: fix / clean up jsdoc comments
Zatan16 opened this issue · comments
Motivation
Many people who use libraries not only use help of jsdoc for methods, but also for the parameters. So, moving the jsdoc declaration from before class to before constructor would definitely help many beginners using this library. Then, the descriptions would show up for the parameters as well.
Examples
No response
Possible workarounds
The possible workaround is that instead of moving the jsdoc completely to before constructor, the description can stay before class but the @param needs to be moved to before constructor
Additional information
You don't need to use tags such as
@classand@constructorwith ES 2015 classes—JSDoc automatically identifies classes and their constructors simply by parsing your code.
as stated by the documentation for classes
Documentation of constructor parameters of course needs to go with the constructor. Feel free to fix this. But a general description of the class should stick with the class and not be moved to the constructor.
But when we keep the description to the constructor, it appears for the main class as well. That's how classes work with jsdoc. So you mean I need to go through all the files and fix it 😅. It's not that I don't want to do it but it's gonna take a lot of grind.
But when we keep the description to the constructor, it appears for the main class as well
I'm not sure what you mean by this. In the documentation you linked, the example is
/** Class representing a point. */
class Point {
/**
* Create a point.
* @param {number} x - The x value.
* @param {number} y - The y value.
*/
constructor(x, y) { ... }
...
}So clearly the description - in this case "Class representing a point" - should stick with the class rather than being moved to the constructor.
So you mean I need to go through all the files and fix it
You don't need to fix it, but you may fix it. You could consider automatizing this with some RegEx; use whatever you are most comfortable with.
It's not that I don't want to do it but it's gonna take a lot of grind.
It's fine, you don't have to fix it by any means. There are more interesting problems to solve than to fix this :)
I'm sorry, I messed up a little. I came here as soon as I realized I messed up and saw your reply. I'm currently working on adding more shapes to the Geometry folder (like the square, rectangle, triangle, cube, etc.)
Also, are there proper guidelines to write the code in? For example, use this and that for jsdoc, or use x spaces or x tabsize for indentation, etc.
Also, are there proper guidelines to write the code in? For example, use this and that for jsdoc, or use x spaces or x tabsize for indentation, etc.
See our contribution guidelines. We use StandardJS style, so 2 spaces for indentation. As for JSDoc: Just refer to their docs for best practice.
I just realized, nowhere in the CONTRIBUTING.md does it say that I don't have to use the ; to end the sentence, so am I allowed to use it? I've seen all files do not use them, I might have missed checking a few.
I just realized, nowhere in the
CONTRIBUTING.mddoes it say that I don't have to use the;to end the sentence, so am I allowed to use it? I've seen all files do not use them, I might have missed checking a few.
I'm not sure what you mean by this. If you mean using semicolons to delimit statements rather than relying on automatic semicolon insertion, please avoid this to comply with StandardJS style. Of course you have to keep using them in for-loops or the like though.
If you're referring to usage of ; as english punctuation: That is allowed within comments. If you do use it, note that it does not end, but rather separate sentences; it is effectively a compromise between a comma (,) and a colon (:). See e.g. Collins Dictionary for how to use semicolons in English.
By sentence, i meant a code line. Thanks for clarifying
@appgurueu please you assign this issue to me
@appgurueu
Please assign this issue to me.