Code Conventions¶

Why? 🤔¶

Use English for naming variables, classes, methods, etc.
Prefix fetch for methods returning a Future.
Prefix watch for methods returning a Stream.
Use de suffix Model for classes that maps a json to an Object. Generally located in /lib/src/features/feature/data/models.

Add validations to every text input field.
Apply tristate pattern (loading, error, data) for every future.
Always provide visual loading information to the user and be sure to prevent this action from being fired again.
Always provide visual error information to the user.

Prefer Stateless for static widgets.
Prefer Stateful for animated widgets.
Prefer Stateful atomic Widgets to wrap Broker Widgets. Example code.
Prefer always separate the Raw Widget from the App State dependent Widget. Example code.

🚫 Extract Widget as class functions. Self explanatory code test can be found here
🚫 Create one line methods that make dificult readability and maintainability.
🚫 Place logic pieces of code on the UI side.
🚫 Mix App State with Ephemeral State. Difference between both can be found here.
🚫 Create private widgets classes, they are not testable. The exception could be the State class of the Stateful widget.
🚫 Deliver code without tests.
🚫 Don't use non-nullable operator without previous check. Example code.
🚫 Don't use Equatable with non App State entity classes.
✅ Use localized text and 🚫 use hardcoded text to show user information.
✅ Use @riverpod annotation with Futures or Streams or return AsynValue.
✅ Use select to get a value from a provider to optimez performance. More info here.
✅ Use const for static widgets.
✅ Use final for widgets that will change its state.
✅ Use final for variables that will not change its state.
✅ Use GoRouter.of(context).push() instead context.push() to navigate to another screen. Same with GoRouter.of(context).pop() and GoRouter.of(context).go().
✅ Always add toEntity and override toString method on the Model classes. Example code

Use BetterComments extension:

//* to help structure views with component names. //? to mark something to ask. //! to prevent the developer of something.

It's ok, try to comment out the changes you made to make reviewer's lives easier.
Add all the requirements or evidence of the developed task.