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 run
flutter build apk --release
ios: flutter build ios --release
web: flutter build web
flutter 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.