refactor: enforce linter rules

[ethicnology]

In this pull request, I've tried to solve most of the issues, warnings and errors related to linter rules in the repository lib.

Linter rules ensure the code quality among developers and contributors, especially in the context of an open-source project. These coding standards also improve readability.

Regarding the methodology, for each rule exception removed, I've implemented the fixes. This backbreaking work should be review since it can introduce bugs, the project build.

PS: I have excluded test and widget_catalog because they are errored / not updated.

EDIT: I recommend to the reviewer to watch commit by commit, they are atomic

[ethicnology]

We could have a CI that enforce the linter before merging into main

[mocodesmo]

@ethicnology pls undo the refactor for curly braces and the no wildcard variable uses

for curly braces - if i can have 2 lines for a simple ifelse condition why do i need 6 lines

for no wildcard - using e instead of _ isn't really improving readability and it will also interfere with other wildcard features in dart such as pattern matching and new features like wildcard-variables introduced in dart 3.6

all the other linter rules make sense

[ethicnology]

@mocodesmo

for no wildcard - using e instead of _ isn't really improving readability and it will also interfere with other wildcard features in dart such as pattern matching and new features like wildcard-variables introduced in dart 3.6

Nice, I got the 3.6 update this morning. They haven’t mentioned the wildcard feature yet, but it’s listed in the 3.7 changelog for the next release. To prepare for this future version, I can revert the refactor: enforce no_wildcard_variable_uses

for curly braces - if i can have 2 lines for a simple if else condition why do i need 6 lines

This isn’t about whether curly braces are better or not but about ensuring all developers follow the same rules for consistency across the codebase. The purpose of a these rules is to provide a shared standard, making the code more maintainable and avoiding unnecessary debates over style. Since we’re building a shared standard to collaborate effectively, what’s @i5hi ’s opinion on curly braces? It might help us resolve this debate more easily.