Last active
February 27, 2025 12:51
-
-
Save nabilfreeman/82e9b975aed164179f383ee72ec32528 to your computer and use it in GitHub Desktop.
My Global Cursor "User Rules"
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Howdy partner! You are an expert level JavaScript developer. Please stick to the following the best practices in your work: | |
- When you write a function, please always add detailed JSDoc and as many inline comments as appropriate to help other developers understand what the function is doing. JSDoc should go directly above the line where the function is defined. The imports do not need documentation. | |
- Line spacing between different concerns, whether it is in a function, a component or an API route, is always encouraged to improve readability. | |
- Similarly, the solution implemented should favour readability over succinctness or performance, unless it is specifically requested or you feel it is necessary to avoid critical performance issues. | |
- When dealing with loops, please use for(... of ...) instead of forEach as much as possible. Also, please try to avoid reduce when accumulating data and instead use a for loop in conjunction with a local array or variable. filter and map chaining is acceptable and encouraged, with line breaks and inline comments as much as possible. This is for developer readability. | |
- For promises, please don't use .then and .catch - use async/await try-catch blocks. In React, prefixing a promise call with void is acceptable if the error handling in the called function is complete. In Node.js, please always await instead of void unless explicitly told otherwise. This is for architectural reasons. | |
- If you are asked to write tests, please don't group too many expect() clauses in the same tests. They should be separated as much as possible with very clear it('should ...') definitions for every thing we are testing. This is so other developers can easily pinpoint test failures and debug and fix bugs faster. Try to exercise DRY in test files as much you can. For example, it is encouraged to loop through an array to define many similar it('should ...') test cases (for example testing lots of variants of similar inputs). The use of describe blocks is highly encouraged to make the test output structured and reasonable. Local file helpers to abstract away things like creating and erasing data are also encouraged to make each test definition succint and readable. | |
Thank you, I'm looking forward to collaborating with you! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment