chore: willboosterify this repo#13
Conversation
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request updates project guidelines and rules across several documentation files and the Cursor configuration, introducing new standards for test debugging, E2E testing, and command syntax. It also updates the oxlint and @typescript/native-preview dependencies. Feedback was provided regarding a change to the commenting rule that encourages using JSDoc to explain "what" code does, as this contradicts the repository's style guide which prioritizes explaining "why" to avoid redundant documentation.
| - Write comments that explain "why" and use JSDoc to explain "what". | ||
| - Avoid stating what can be easily understood from the code itself. |
There was a problem hiding this comment.
The proposed rule contradicts the repository style guide, which states that comments should explain "why" rather than "what". Explicitly encouraging the use of JSDoc to explain "what" may lead to redundant documentation that states the obvious, which is discouraged by the rule to avoid stating what can be understood from the code itself.
- Write comments that explain "why" rather than "what".
- Avoid stating what can be understood from the code itself.
References
- Write comments that explain "why" rather than "what". Avoid stating what can be understood from the code itself. (link)
| - Write comments that explain "why" and use JSDoc to explain "what". | ||
| - Avoid stating what can be easily understood from the code itself. |
There was a problem hiding this comment.
The proposed rule contradicts the repository style guide, which states that comments should explain "why" rather than "what". Explicitly encouraging the use of JSDoc to explain "what" may lead to redundant documentation that states the obvious, which is discouraged by the rule to avoid stating what can be understood from the code itself.
| - Write comments that explain "why" and use JSDoc to explain "what". | |
| - Avoid stating what can be easily understood from the code itself. | |
| - Write comments that explain "why" rather than "what". | |
| - Avoid stating what can be understood from the code itself. |
References
- Write comments that explain "why" rather than "what". Avoid stating what can be understood from the code itself. (link)
| - Write comments that explain "why" and use JSDoc to explain "what". | ||
| - Avoid stating what can be easily understood from the code itself. |
There was a problem hiding this comment.
The proposed rule contradicts the repository style guide, which states that comments should explain "why" rather than "what". Explicitly encouraging the use of JSDoc to explain "what" may lead to redundant documentation that states the obvious, which is discouraged by the rule to avoid stating what can be understood from the code itself.
| - Write comments that explain "why" and use JSDoc to explain "what". | |
| - Avoid stating what can be easily understood from the code itself. | |
| - Write comments that explain "why" rather than "what". | |
| - Avoid stating what can be understood from the code itself. |
References
- Write comments that explain "why" rather than "what". Avoid stating what can be understood from the code itself. (link)
| - Write comments that explain "why" and use JSDoc to explain "what". | ||
| - Avoid stating what can be easily understood from the code itself. |
There was a problem hiding this comment.
The proposed rule contradicts the repository style guide, which states that comments should explain "why" rather than "what". Explicitly encouraging the use of JSDoc to explain "what" may lead to redundant documentation that states the obvious, which is discouraged by the rule to avoid stating what can be understood from the code itself.
| - Write comments that explain "why" and use JSDoc to explain "what". | |
| - Avoid stating what can be easily understood from the code itself. | |
| - Write comments that explain "why" rather than "what". | |
| - Avoid stating what can be understood from the code itself. |
References
- Write comments that explain "why" rather than "what". Avoid stating what can be understood from the code itself. (link)
1 participant
No description provided.