From d7b3e20233a8fa2e9b62dd8fe46acea86dcdacb8 Mon Sep 17 00:00:00 2001 From: overtrue Date: Sun, 25 May 2025 13:34:06 +0800 Subject: [PATCH] docs: enhance cursor rules with code quality standards --- .cursorrules | 16 +++++++++++++++- 1 file changed, 15 insertions(+), 1 deletion(-) diff --git a/.cursorrules b/.cursorrules index ae780deb..09435542 100644 --- a/.cursorrules +++ b/.cursorrules @@ -37,12 +37,17 @@ single_line_let_else_max_width = 100 - Use `PascalCase` for types, traits, enums - Constants use `SCREAMING_SNAKE_CASE` - Global variables prefix `GLOBAL_`, e.g., `GLOBAL_Endpoints` +- Use meaningful and descriptive names for variables, functions, and methods +- Avoid meaningless names like `temp`, `data`, `foo`, `bar`, `test123` +- Choose names that clearly express the purpose and intent ### 3. Documentation Comments - Public APIs must have documentation comments - Use `///` for documentation comments - Complex functions add `# Examples` and `# Parameters` descriptions - Error cases use `# Errors` descriptions +- Always use English for all comments and documentation +- Avoid meaningless comments like "debug 111" or placeholder text ### 4. Import Guidelines - Standard library imports first @@ -182,6 +187,13 @@ mod tests { - Use `e2e_test` module for end-to-end testing - Simulate real storage environments +### 3. Test Quality Standards +- Write meaningful test cases that verify actual functionality +- Avoid placeholder or debug content like "debug 111", "test test", etc. +- Use descriptive test names that clearly indicate what is being tested +- Each test should have a clear purpose and verify specific behavior +- Test data should be realistic and representative of actual use cases + ## Security Guidelines ### 1. Memory Safety @@ -336,7 +348,9 @@ These rules should serve as guiding principles when developing the RustFS projec - Always check the .cursorrules file before starting to ensure you understand the project guidelines - Before starting any change or requirement development, first git checkout to main branch, then git pull to get the latest code - For each feature or change to be developed, first create a branch, then git checkout to that branch - - Use English for code comments, do not use Chinese + - Use English for all code comments, documentation, and variable names + - Write meaningful and descriptive names for variables, functions, and methods + - Avoid meaningless test content like "debug 111" or placeholder values - Before each change, carefully read the existing code to ensure you understand the code structure and implementation, do not break existing logic implementation, do not introduce new issues - Ensure each change provides sufficient test cases to guarantee code correctness - Do not arbitrarily modify numbers and constants in test cases, carefully analyze their meaning to ensure test case correctness