51 lines
2.3 KiB
Markdown
51 lines
2.3 KiB
Markdown
## General Guidelines for Code Generation
|
|
|
|
- **Overall Style:**
|
|
- Write clear, concise, and well-commented code.
|
|
- Follow idiomatic coding practices that prioritize readability, maintainability, and simplicity.
|
|
- Apply the DRY (Don't Repeat Yourself) principle to avoid duplication.
|
|
|
|
## Backend (Go) Specifics
|
|
|
|
- **Routing & Handlers:**
|
|
|
|
- Use go-chi for routing and maintain a modular structure.
|
|
- Write handler functions that perform one clear task: parsing requests, interacting with PostgreSQL, and returning JSON responses.
|
|
- Include inline comments to explain complex logic and error handling.
|
|
|
|
- **Error Handling & Patterns:**
|
|
|
|
- Check for errors at each step and use context-aware patterns.
|
|
- Use proper naming conventions (camelCase for variables and PascalCase for types).
|
|
|
|
- **Database & Caching:**
|
|
- When interacting with PostgreSQL, use environment variables (e.g., `DATABASE_URL`) to read connection details and use parameterized queries to prevent SQL injection.
|
|
- For Redis, initialize the client with context and perform error checking to ensure the connection is stable.
|
|
|
|
## Swagger Documentation
|
|
|
|
- **API Documentation:**
|
|
- Generate Swagger (OpenAPI) YAML snippets to document each endpoint, including parameters, expected responses, and error messages.
|
|
- Ensure the Swagger docs are clear and adhere to standardized formats.
|
|
|
|
## Frontend (NuxtJS) Specifics
|
|
|
|
- **Setup & Configuration:**
|
|
- Assume a client-side only NuxtJS application.
|
|
- Generate lightweight, reusable Vue components using the Composition API.
|
|
- Use async/await syntax for API calls and refer to environment variables (e.g., API base URL) for configuration.
|
|
|
|
## Commit & PR Messaging
|
|
|
|
- **Descriptive Messaging:**
|
|
- When generating commit messages or pull request descriptions, include:
|
|
- A short summary of the changes.
|
|
- The reason for the changes.
|
|
- Optionally, emojis to indicate the type of update (e.g., :sparkles: for features, :bug: for fixes).
|
|
|
|
## Additional Guidance & Context
|
|
|
|
- **Suggestions & Improvements:**
|
|
- When proposing code changes, suggest alternative approaches or improvements, particularly around error handling, security, and performance optimization.
|
|
- Ask clarifying questions if the context is unclear to ensure alignment with project requirements.
|