066eb8f820
Music Creation Page: - Vinyl 3D flip to view lyrics, tonearm animation, glow rotation effect - Circular SVG progress ring, speech bubble feedback, confirm dialog - Playlist modal, free creation input, lyrics formatting optimization - MiniMax API real music generation with SSE streaming progress Backend: - FastAPI proxy server.py for MiniMax API calls - Music + lyrics file persistence to Capybara music/ directory - GET /api/playlist endpoint for auto-building playlist from files UI/UX Refinements: - frontend-design skill compliance across all pages - Glassmorphism effects, modal interactions, scroll tap prevention - iPhone 12 Pro responsive layout (390x844) Flutter Development Preparation: - Installed flutter-expert skill with 6 reference docs - Added 5 Cursor Rules: official Flutter, clean architecture, UI performance, testing, Dart standards Assets: - 9 Capybara music MP3 files + lyrics TXT files - MiniMax API documentation Co-authored-by: Cursor <cursoragent@cursor.com>
71 lines
2.5 KiB
Plaintext
71 lines
2.5 KiB
Plaintext
---
|
|
description: Dart language coding standards and conventions. Apply to ALL Dart files.
|
|
globs: "**/*.dart"
|
|
---
|
|
|
|
# Dart Coding Standards
|
|
|
|
## Naming Conventions
|
|
- PascalCase for classes, enums, typedefs, extensions.
|
|
- camelCase for variables, functions, methods, parameters.
|
|
- snake_case for file and directory names.
|
|
- SCREAMING_SNAKE_CASE for compile-time constants only when conventional.
|
|
- Start functions with a verb: fetchUser(), saveSettings(), isValid().
|
|
- Use boolean prefixes: isLoading, hasError, canDelete, shouldRefresh.
|
|
- Use complete words, avoid abbreviations (except API, URL, i/j for loops).
|
|
|
|
## Functions
|
|
- Short, single purpose, < 20 lines.
|
|
- Arrow syntax for simple one-line functions.
|
|
- Named parameters for > 2 parameters.
|
|
- Default parameter values instead of null checks.
|
|
- Reduce parameters using parameter objects (RO-RO pattern).
|
|
- Single level of abstraction per function.
|
|
- Early return to avoid deep nesting.
|
|
|
|
## Classes
|
|
- Follow SOLID principles.
|
|
- Prefer composition over inheritance.
|
|
- Small classes: < 200 lines, < 10 public methods, < 10 properties.
|
|
- Declare interfaces (abstract classes) for contracts/repositories.
|
|
- Use factory constructors for complex initialization.
|
|
|
|
## Data & Immutability
|
|
- Prefer immutable data structures.
|
|
- Use final for fields that don't change.
|
|
- Use const for compile-time constants.
|
|
- Encapsulate data in composite types (avoid primitive obsession).
|
|
- Use Freezed for complex immutable state classes.
|
|
|
|
## Null Safety
|
|
- Write soundly null-safe code.
|
|
- Avoid ! operator unless value is guaranteed non-null.
|
|
- Use ?. and ?? operators appropriately.
|
|
- Prefer required named parameters over nullable ones.
|
|
|
|
## Error Handling
|
|
- Use try-catch for expected exceptions.
|
|
- Create custom exception classes for domain-specific errors.
|
|
- Never catch generic Exception without rethrowing or logging.
|
|
- Use Either<Failure, T> for functional error handling in repositories.
|
|
|
|
## Async
|
|
- Use async/await (not .then() chains).
|
|
- Use Future for single async operations.
|
|
- Use Stream for sequences of async events.
|
|
- Handle errors in every async operation.
|
|
- Cancel subscriptions in dispose().
|
|
|
|
## Code Organization
|
|
- One primary export per file.
|
|
- Group related libraries in the same folder.
|
|
- Use part/part of sparingly; prefer separate files.
|
|
- Import order: dart:, package:, relative imports.
|
|
|
|
## Documentation
|
|
- /// for all public API doc comments.
|
|
- First line: concise summary ending with period.
|
|
- Explain WHY, not WHAT.
|
|
- Use backtick fences for code samples.
|
|
- Place doc comments before annotations.
|