code-style

Instruction file imported from vasu-nageshri-simform/Get_it (.github/instructions/code-style.instructions.md). Copyright stays with the author.

Naming Conventions

1. Variables/Methods: lowerCamelCase (e.g., fetchUserData())
2. Constants: lowerCamelCase (e.g., maxRetries)
3. Private members: Prefix with underscore (e.g., _validateForm())
4. Booleans: Use positive phrasing (e.g., isEnabled, hasError)

File Naming Standards

1. All files: Use snake_case naming
2. Navigation Model files: Always suffix with _nav_dm.dart - e.g., user_profile_nav_dm.dart
3. Request models: Always suffix with _req_dm.dart - e.g., login_req_dm.dart
4. Response models: Always suffix with _res_dm.dart - e.g., login_res_dm.dart
5. Cubit file: Always suffix with _cubit.dart - e.g., user_profile_cubit.dart
6. State file: Always suffix with _state.dart - e.g., user_profile_state.dart
7. Screen files: Always suffix with _screen.dart - e.g., user_profile_screen.dart

Class Naming Standards

1. All classes: Use UpperCamelCase
2. Model classes: Always suffix with Dm - e.g., UserProfileDm, LoginReqDm
3. Cubit class: Always suffix with Cubit - e.g., UserProfileCubit
4. State class: Always suffix with State - e.g., UserProfileState
5. Screen classes: Always suffix with Screen - e.g., UserProfileScreen
6. Widget classes: Use descriptive names without suffixes - e.g., ProfileCard, LoadingIndicator
   • If needed use suffix Widget - e.g., ProfileCardWidget

Modern Dart 3 Features

1. Records: (String, int) getUserInfo() => ('John', 25);
2. Pattern Matching and Switch expressions: final value = switch(response) { Success(data:var d) => d, Error() => null };
3. Sealed Classes: For exhaustive type hierarchies like API states

UI Development Guidelines

1. Use Gap instead of SizedBox for spacing: Gap(8.w) instead of SizedBox(width: 8.w)
2. Avoid separate methods for single-use widgets - inline them instead
3. Minimize unnecessary comments - only add for complex logic, separations in large files, or TODOs
4. Use responsive extensions: .w, .h, .r, .sp for all sizing
5. Business logic in models: Add computed properties to data models for UI logic
6. Use type-safe asset references: Assets.vectors.iconName.svg() instead of hardcoded paths

Development & Performance Guidelines

1. Always ask for more information if you are not sure about something rather than making assumptions
2. Each widget should be in its own file with the same name as the widget class
3. Avoid creating functions to return widgets; instead, use widget classes
4. Use const constructors for widgets and classes
5. Always check lib/utilities/extensions/ for extensions method that can be used to simplify code and avoid boilerplate
6. Use RepaintBoundary for widgets that need to be repainted separately to improve performance
7. Implement pagination for long lists using paginated_list.dart
8. Prefer stateless widgets over stateful widgets when possible
9. Use lazy loading for heavy resources
10. Properly dispose of controllers, animations, and stream subscriptions
11. Use weak references for callbacks to avoid memory leaks
12. Implement efficient caching strategies
13. Utilise isolate for heavy computations
14. Always run dart run build_runner build -d after store, model, asset or env file changes
15. Avoid to create, modify or refer (as context) the generated files (*.g.dart)
16. Avoid creating sample demo code and ask for which screen/module is to be modified
17. Follow software engineering best practices, principles and design patterns like SOLID, DRY, returning early in a function, etc

Documentation

1. Format comments like sentences.
2. Use /// doc comments to document members and types; don't use block comments for documentation.
3. Prefer writing doc comments for public APIs.
4. Consider writing doc comments for private APIs.
5. Consider including explanations of terminology, links, and references in library-level docs.
6. Start doc comments with a single-sentence summary.
7. Separate the first sentence of a doc comment into its own paragraph.
8. Use square brackets in doc comments to refer to in-scope identifiers.
9. Use prose to explain parameters, return values, and exceptions.
10. Put doc comments before metadata annotations.
11. Document why code exists or how it should be used, not just what it does.
12. Avoid unnecessary comments - only comment complex logic, separations in large files, or TODOs.

Code Quality and Linting

1. Run dart format to format your code before committing
2. Run dart analyze to check for any issues
3. Use dart fix --apply to automatically fix common issues
4. Follow rules mentioned in analysis_options.yaml file

Resources

Refer to the following resources for further guidance and best practices:

• Effective Dart for best practices
• Flutter Documentation for official guides and API references
• Very good code lint for code quality