
build_and_development_commands:
flutter pub get after cloning or adding packages.flutter pub run build_runner build --delete-conflicting-outputs to generate files.flutter runflutter build apk --release
ios: flutter build ios --release
web: flutter build webflutter clean.env or Flutter flavors.testing_guidelines:
unit_tests:
- Use test package.
- Mock dependencies with mocktail or mockito.
- Keep logic pure and testable.
widget_tests:
- Use flutter_test and WidgetTester.
- Test rendering and user interaction.
integration_tests:
- Use integration_test package.
- Write end-to-end flows for user scenarios.
coverage:
- Run all tests: flutter test
- Generate coverage report: flutter test --coverage
code_style_and_guidelines:
linting:
- Use flutter_lints or very_good_analysis.
architecture:
- Follow Clean Architecture.
- Organize code by feature.
state_management:
- Use one approach per app: Riverpod, Bloc, or Provider.
naming_conventions:
class: PascalCase
variable: camelCase
constant: SCREAMING_SNAKE_CASE
widgets:
- Keep widgets small and composable.
- Extract complex widgets into separate files.
formatting:
- Use dart format . before committing.
general_rules:
- No hardcoded strings or styles.
- Use logger instead of print().
- Remove all debugging code before release.
documentation_guidelines:
readme:
- Overview of the project.
- Setup and install instructions.
- Folder structure.
- Architecture and state management.
- How to run and test.
code_comments:
- Use /// for public classes and methods.
- Describe purpose, parameters, and return types.
changelog:
- Maintain CHANGELOG.md with versioned updates.
internal_docs:
- Add /docs folder for architecture diagrams or API flowcharts.
generated_docs:
- Use dart doc for generating reference documentation.