chore: clean up instructions
This commit is contained in:
@@ -208,34 +208,6 @@ These instructions are based on:
|
|||||||
- Handle errors at the appropriate level
|
- Handle errors at the appropriate level
|
||||||
- Consider using structured errors for better debugging
|
- Consider using structured errors for better debugging
|
||||||
|
|
||||||
## API Design
|
|
||||||
|
|
||||||
### HTTP Handlers
|
|
||||||
|
|
||||||
- Use `http.HandlerFunc` for simple handlers
|
|
||||||
- Implement `http.Handler` for handlers that need state
|
|
||||||
- Use middleware for cross-cutting concerns
|
|
||||||
- Set appropriate status codes and headers
|
|
||||||
- Handle errors gracefully and return appropriate error responses
|
|
||||||
- Use `github.com/go-chi/chi/v5` for its `mux` with pattern-based routing and method matching
|
|
||||||
|
|
||||||
### JSON APIs
|
|
||||||
|
|
||||||
- Use struct tags to control JSON marshaling
|
|
||||||
- Validate input data
|
|
||||||
- Use pointers for optional fields
|
|
||||||
- Consider using `json.RawMessage` for delayed parsing
|
|
||||||
- Handle JSON errors appropriately
|
|
||||||
|
|
||||||
### HTTP Clients
|
|
||||||
|
|
||||||
- Keep the client struct focused on configuration and dependencies only (e.g., base URL, `*http.Client`, auth, default headers). It must not store per-request state
|
|
||||||
- Do not store or cache `*http.Request` inside the client struct, and do not persist request-specific state across calls; instead, construct a fresh request per method invocation
|
|
||||||
- Methods should accept `context.Context` and input parameters, assemble the `*http.Request` locally (or via a short-lived builder/helper created per call), then call `c.httpClient.Do(req)`
|
|
||||||
- If request-building logic is reused, factor it into unexported helper functions or a per-call builder type; never keep `http.Request` (URL params, body, headers) as fields on the long-lived client
|
|
||||||
- Ensure the underlying `*http.Client` is configured (timeouts, transport) and is safe for concurrent use; avoid mutating `Transport` after first use
|
|
||||||
- Always set headers on the request instance you’re sending, and close response bodies (`defer resp.Body.Close()`), handling errors appropriately
|
|
||||||
|
|
||||||
## Performance Optimization
|
## Performance Optimization
|
||||||
|
|
||||||
### Memory Management
|
### Memory Management
|
||||||
@@ -350,18 +322,15 @@ These instructions are based on:
|
|||||||
|
|
||||||
### Essential Tools
|
### Essential Tools
|
||||||
|
|
||||||
- `go fmt`: Format code
|
- `make fmt`: Format code
|
||||||
- `go vet`: Find suspicious constructs
|
- `make lint`: Additional linting
|
||||||
- `golangci-lint`: Additional linting
|
- `make test`: Run tests
|
||||||
- `go test`: Run tests
|
|
||||||
- `go mod`: Manage dependencies
|
- `go mod`: Manage dependencies
|
||||||
- `go generate`: Code generation
|
|
||||||
|
|
||||||
### Development Practices
|
### Development Practices
|
||||||
|
|
||||||
- Run tests before committing
|
- Run tests before committing (`make test`)
|
||||||
- Run linter before committing
|
- Run linter before committing (`make lint`)
|
||||||
- Run `make sqlc`, `make openapi-gen` and `make readme-gen` before committing if you touched related files
|
|
||||||
- Keep commits focused and atomic
|
- Keep commits focused and atomic
|
||||||
- Write meaningful commit messages
|
- Write meaningful commit messages
|
||||||
- Review diffs before committing
|
- Review diffs before committing
|
||||||
|
|||||||
Reference in New Issue
Block a user