add cursor rules group #2
This commit is contained in:
parent
d3e61d2ad4
commit
9d7b813f05
28
.cursorrules
28
.cursorrules
@ -23,4 +23,30 @@
|
||||
4. Consistency & Tools Integration:
|
||||
- Leverage existing tools like Prettier and ESLint to automatically enforce style and formatting rules in both backend and frontend codebases.
|
||||
- Use TypeScript in the frontend to ensure type safety and catch errors early in the development cycle.
|
||||
- Maintain uniformity in API design and error handling strategies (e.g., consistent use of passport for authentication and common error handling middleware).
|
||||
- Maintain uniformity in API design and error handling strategies (e.g., consistent use of passport for authentication and common error handling middleware).
|
||||
## Group 2 – Naming Conventions
|
||||
|
||||
1. File Naming and Structure:
|
||||
• Frontend:
|
||||
- Page Files: Use lower-case filenames (e.g., index.tsx) as prescribed by Next.js conventions.
|
||||
- Component Files: Use PascalCase for React component files (e.g., WebSiteHeader.tsx, NavBar.tsx).
|
||||
- Directories: Use clear, descriptive names (e.g., 'pages', 'components', 'WebPageComponents').
|
||||
• Backend:
|
||||
- Use lower-case filenames for modules (e.g., index.js, auth.js, projects.js).
|
||||
- When needed, use hyphenation for clarity, but maintain consistency.
|
||||
|
||||
2. Component and Module Naming:
|
||||
• Frontend:
|
||||
- React Components: Define components in PascalCase.
|
||||
- TypeScript Interfaces/Types: Use PascalCase (e.g., WebSiteHeaderProps).
|
||||
• Backend:
|
||||
- Classes (if any) and constructors should be in PascalCase; most helper functions and modules use camelCase.
|
||||
|
||||
3. Variable, Function, and Hook Naming:
|
||||
• Use camelCase for variables and function names in both frontend and backend (e.g., useAppSelector, handleMenuNavBarToggleClick, wrapAsync).
|
||||
• Custom Hooks: Prefix with ‘use’ (e.g., useAuth, useForm).
|
||||
|
||||
4. Consistency and Readability:
|
||||
• Maintain uniform naming across the project to ensure clarity and ease of maintenance.
|
||||
• New code must adhere to these conventions to avoid ambiguity.
|
||||
• Use descriptive names that reflect the purpose and domain, avoiding abbreviations unless standard in the project.
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user