| title | Coding Standards |
|---|
& Best Practices
To maintain the high quality of this codebase, strict adherence to the following standards is required.
The Domain layer must be pure Dart.
- Bad:
import 'package:flutter/material.dart'; - Good:
import 'package:equatable/equatable.dart';
Keep Data sources framework-agnostic.
- Bad:
debugPrint('error') - Good:
Logger.error('error')(fromcore/utils)
Do not throw exceptions in Use Cases or Repositories.
- Bad:
Future<User>(throws exception) - Good:
Future<Either<Failure, User>>
Avoid StateProvider or ChangeNotifier for complex state.
- Why: Better testability and lifecycle management.
- Data Providers: Place in
features/[feature]/providers/. Define Repositories/UseCases/DataSources. - UI Providers: Place in
features/[feature]/presentation/providers/. DefineNotifiers for screens.
- Watch: For values that trigger rebuilds.
- Read: For one-time actions (button clicks).
Always explicitly type return values and arguments.
// Bad
var x = 10;
getUser() { ... }
// Good
int x = 10;
Future<User> getUser() { ... }Always use trailing commas for better formatting.
Use relative imports for files inside the same feature.
import '../domain/entities/user.dart'; // GoodUse package imports for crossing feature boundaries or core.
import 'package:app/core/utils/logger.dart'; // GoodUse mocktail to mock Repositories when testing Use Cases, and RemoteDataSources when testing Repositories.
Ideally, every Use Case should have unit tests covering Success and Failure paths.
Use Golden tests for complex screens to prevent visual regression.