[style] update analyzer options to the recommended lint set

[pq]

Transitioning from pedantic to recommended lints there are a number of lints disabled that need vetting.

• [ ] avoid_renaming_method_parameters
• [x] camel_case_types
• [ ] constant_identifier_names
• [ ] hash_and_equals
• [ ] non_constant_identifier_names
• [ ] implementation_imports
• [ ] library_private_types_in_public_api
• [x] overridden_fields
• [ ] provide_deprecation_message

[asashour]

I hope it is fine to raise those CLs here. As recently mentioned, returns types should be declared.

This CL declares the return type of main(), it was done using IDE replacement (only main() { at line beginning of line):

https://dart-review.googlesource.com/c/sdk/+/257340

Async main() and some analysis_server functions: https://dart-review.googlesource.com/c/sdk/+/257342

The test methods https://dart-review.googlesource.com/c/sdk/+/257343

[bwilkerson]

This issue appears to be a request to decide which of the listed lints we should enforce in the analyzer packages. I think we should make those decisions before we attempt to enforce the lints.

That said, the CLs above appear to be enforcing type_annotate_public_apis, which isn't on the list. While I believe that we should enable that lint (we follow it 90+% of the time, and consistency in this area would be a good thing imo), that also hasn't been decided.

[asashour]

The CLs lint is more of always_declare_return_types (which is not on the list), and it was hinted few times during reviews.

The CLs are split mainly for main() and for test_ methods.

[pq]

This issue appears to be a request to decide which of the listed lints we should enforce in the analyzer packages.

Also FYI @devoncarew who is in conversations about defining (and enforcing) a dart team lint set (which may or may not derive from the current recommended rules).

[devoncarew]

FWIW, a dart team rule set - once defined - would definitely be strict super-set of package:lints/recommended.yaml.