feat: add lint rules

[josxha]

Lint rules in concideration:

• use_decorated_box
• use_is_even_rather_than_modulo
• unnecessary_lambdas
• sort_pub_dependencies
• prefer_void_to_null
• unnecessary_raw_strings
• comment_references
• parameter_assignments
• avoid_unused_constructor_parameters

Let me know if you want any of them not included.

edit: Having all these manual lint rules it might help to concider using more restrictive lint list than the default flutter list.

[JaffaKetchup]

LGTM, I agree with all these lints. We can always add more later.

FYI the entire list of supported lints is at https://dart.dev/tools/linter-rules/all, and we can just remove the conflicting ones from there (eg. prefer single or double quotes).

[josxha]

FYI the entire list of supported lints is at https://dart.dev/tools/linter-rules/all, and we can just remove the conflicting ones from there (eg. prefer single or double quotes).

I'm in favour of adding more lint rules. But we might concider using another lint package and adjusting it from there to make the most out of lints as we don't really want to maintain our own lint list. Adding new lints, deactivating lints that cause issues (some lints are only experimentell and have false positivies).

There is an awesome comparison between the most common strict lint packages in this blog article. Especially the linked spreadsheet gives a really detailed comparison.

• RydMike's list is the most restrictive. But he hasn't released it as package.
• Lint and Very Good Analysis are probably both solid choises for restrictive rulesets. And if we don't want any rule, we can still manually override it.

[JaffaKetchup]

Yeah, I've seen those before. I do actually maintain my own lint set, and update it with every major Flutter release, because I don't fully trust packages to stay up to date.

[josxha]

I do actually maintain my own lint set, and update it with every major Flutter release

Oh I didn't knew about that. Do you have the list somewhere? I can only find it included in your packages like here.

because I don't fully trust packages to stay up to date.

That's a understandable concern, but I wouldn't be too worried since they seem to be maintained well and if they become abandoned we can simply swap them out since it is only a dev dependency.