Update badge in packages that depend on effective_dart, ergo changing URL from GitHub to Pub, to remove the dependency to this repository URL in case sometimes it gets transformed.

• Bloc
• Equatable
• Hydrated Bloc (felangel/hydrated_bloc#59)
• ...

New badge markdown:

[![style: effective dart](https://img.shields.io/badge/style-effective_dart-40c4ff.svg)](https://pub.dev/packages/effective_dart)

Hi!

Looking at advice for imports, it looks like we're suggesting conflicting rules:

Or maybe the docs need to be updated?

Hello! I would like to know how to put certain actions to be executed automatically when the auto formatter is used.

I'm currently using VS Code, and I would like all my imports to be changed to relative imports, and then, automatically organized. Any idea how to do this?

It would be nice to share this package, so people can discover it exists.

It is already mentioned in linter repository, next to pedantic package, and it will be shown in linter lints page.

I would like to share it to sources like awesome dart, flutter etc.

Tips where we can share it are welcomed!

Hello! thanks for the awesome package.

Dart 2.12 and flutter 2.0.0 are now in stable with the null-safety feature.

Migrating this package to null-safety would help a lot. :)

The effective dart linter generates an error on future.catchError:

 future
        .catchError((Object e, StackTrace st) => print('onErrr: $e'))

The .catchError method requires that you pass the types.

As such this rule needs to be explicitly ignored every time.

It would be good if the linter was smart enough to recognize this situation and suppress the lint.

From the Effective Dart, you have these severity types:

• DO guidelines describe practices that should always be followed. There will almost never be a valid reason to stray from them.
• DON’T guidelines are the converse: things that are almost never a good idea. Hopefully, we don’t have as many of these as other languages do because we have less historical baggage.
• PREFER guidelines are practices that you should follow. However, there may be circumstances where it makes sense to do otherwise. Just make sure you understand the full implications of ignoring the guideline when you do.
• AVOID guidelines are the dual to “prefer”: stuff you shouldn’t do but where there may be good reasons to on rare occasions.
• CONSIDER guidelines are practices that you might or might not want to follow, depending on circumstances, precedents, and your own preference.

And as I understand, you can use four types of severity for analyzer:

• error
• warning
• info
• ignore

And more info about how it can be done here: https://dart.dev/guides/language/analysis-options#the-analysis-options-file

I would like to (and this is not opinionated, it would be nice to have in general to determine these types from the guide in the editor) reflect the type of usage from guidelines in Effective Dart, so do and don't rules are treated as they have to be done this way and prefer and avoid as only optional? With that, without enabling thins like --fatal-infos and --fatal-warnings, it would be good if analyzer would fail for dos and don'ts and don't fail for prefers and avoids.

1. Does this have a sense, is it worth it?

For example, in pedantic package, there is written "By default we disallow checking in code with any errors, warnings, or hints." and that might work if all the lints are given the same severity, but Effective Dart doesn't have this benefit. 🤷‍♂️

2. Can I use error for dos and don'ts, or it's too hard? Should I use warning for that?
3. If error will be used for dos and don'ts, then warning for prefers and avoids and info for considers?
4. if considers would have info, and therefore be shown as a "something" from Dart Analyser, wouldn't that force people to use it, whereas this section isn't always what you want to do? So maybe omit considers?

I would like some comments, mostly to be as aligned as possible with the guide intention.
Maybe cc @pq @kwalrath ...

BAD:
var names = people.map((Person person) => person.name);

GOOD:
var names = people.map((person) => person.name);

This is the example you gave but whenever I implement the approved method I get errors "Missing parameter type person"

analysis_options.yaml

include: package:effective_dart/analysis_options.yaml

analyzer:
  exclude:
    - "build/**"
    - "lib/generated/**"
  strong-mode: 
    implicit-casts: false
    implicit-dynamic: false

linter:
  rules:
    - camel_case_types

as for the title, please consider adding the experimental lint avoid_dynamic_calls
thank you

We are getting this error at pub.dev:

Details also at https://pub.dev/api/packages/effective_dart/metrics?pretty&reports

The reason is probably because of dart-lang/pana#591 which has been fixed by dart-lang/pana#592 (but will be published later).

I would like to discuss and maybe reconsider adding the lines_longer_than_80_chars lint rule.

This package should aim to follow the Effective Dart guide as much as possible and disabling this lint rule is probably opinionated. Given the fact that you can easily suppress any lint rule per project, file or line, I would like to reconsider this and add it to the lints we use.

Cc @felangel as you have for now the biggest projects using this package.

After approval of dart-lang/site-www#2190, add avoid_catching_errors.

The README says that this is heavily influenced by pedantic. But it's unclear what the goal or difference is. It would be great if you could add a small sentence or paragraph to the README explaining the difference between the two, so it's easier to decide whether pedantic or effective should be used.

Thanks

After approval of dart-lang/site-www#2187, add implementation_imports.

I do not know if the problem is with vscode although I suspect that it is some kind of configuration issue. Here's the error I'm getting when I use effective_dart in some of my projects:

The include file package:effective_dart/analysis_options.yaml in [...]analysis_options.yaml cannot be found.

I've checked that the path is correct, if I change the line of the include and then change it back to exactly what it was before the problem will go away, but I have to do this every time I open this particular project. Also I tried changing the include to use a specific version number and I have the same behavior on load.

Any idea what is going on?

Add badge to all lints used by package:effective_dart on page http://dart-lang.github.io/linter/lints/.

Cc: dart-lang/linter#1781

That would probably include changing files:

• https://github.com/dart-lang/linter/blob/f1bce463d96b1af6b02da1fe220ddbce6ef793a3/tool/scorecard.dart
• https://github.com/dart-lang/linter/blob/93f55b10950d9cb08c23a56978fdaa6d09dee5d9/tool/crawl.dart
• https://github.com/dart-lang/linter/blob/c2182f0c58b130aaa9dde14e91908e7885d9fbcb/tool/doc.dart

Used will be the badge from README of this project.

Linter project can be, probably, build using tool/doc.dart or some other file there.

Hi @tenhobi,
I got an warning 'add curly braces to all if and else statements' in intellij on a line. When i press quick fix it, it fixed it for that particular line. Its very difficult to add curly braces to every if else in my flutter application.
Is there a way to fix all files instead of fixing that current line in one go?
I remember in eslint it gave an option to fix for all files.

using effective_dart: ^1.3.0 // ignore_for_file: non_constant_identifier_names

doesn't seem to work here

   info • Prefer using lowerCamelCase for constant names • subiquity_client/lib/src/types.dart:23:3 • constant_identifier_names
   info • Prefer using lowerCamelCase for constant names • subiquity_client/lib/src/types.dart:24:3 • constant_identifier_names
   info • Prefer using lowerCamelCase for constant names • subiquity_client/lib/src/types.dart:25:3 • constant_identifier_names
   info • Prefer using lowerCamelCase for constant names • subiquity_client/lib/src/types.dart:26:3 • constant_identifier_names
   info • Prefer using lowerCamelCase for constant names • subiquity_client/lib/src/types.dart:27:3 • constant_identifier_names
   info • Prefer using lowerCamelCase for constant names • subiquity_client/lib/src/types.dart:28:3 • constant_identifier_names
   info • Prefer using lowerCamelCase for constant names • subiquity_client/lib/src/types.dart:29:3 • constant_identifier_names
   info • Prefer using lowerCamelCase for constant names • subiquity_client/lib/src/types.dart:30:3 • constant_identifier_names
   info • Prefer using lowerCamelCase for constant names • subiquity_client/lib/src/types.dart:31:3 • constant_identifier_names
   info • Prefer using lowerCamelCase for constant names • subiquity_client/lib/src/types.dart:32:3 • constant_identifier_names
   info • Prefer using lowerCamelCase for constant names • subiquity_client/lib/src/types.dart:33:3 • constant_identifier_names
   info • Prefer using lowerCamelCase for constant names • subiquity_client/lib/src/types.dart:37:3 • constant_identifier_names
   info • Prefer using lowerCamelCase for constant names • subiquity_client/lib/src/types.dart:38:3 • constant_identifier_names
   info • Prefer using lowerCamelCase for constant names • subiquity_client/lib/src/types.dart:39:3 • constant_identifier_names
   info • Prefer using lowerCamelCase for constant names • subiquity_client/lib/src/types.dart:40:3 • constant_identifier_names
   info • Prefer using lowerCamelCase for constant names • subiquity_client/lib/src/types.dart:41:3 • constant_identifier_names
   info • Prefer using lowerCamelCase for constant names • subiquity_client/lib/src/types.dart:45:3 • constant_identifier_names
   info • Prefer using lowerCamelCase for constant names • subiquity_client/lib/src/types.dart:46:3 • constant_identifier_names
   info • Prefer using lowerCamelCase for constant names • subiquity_client/lib/src/types.dart:47:3 • constant_identifier_names
   info • Prefer using lowerCamelCase for constant names • subiquity_client/lib/src/types.dart:48:3 • constant_identifier_names
   info • Prefer using lowerCamelCase for constant names • subiquity_client/lib/src/types.dart:49:3 • constant_identifier_names
   info • Prefer using lowerCamelCase for constant names • subiquity_client/lib/src/types.dart:50:3 • constant_identifier_names
   info • Prefer using lowerCamelCase for constant names • subiquity_client/lib/src/types.dart:51:3 • constant_identifier_names

23 issues found. (ran in 19.7s; 146 public members lack documentation)

maybe related to this dart-lang/linter#204

Thanks for this cool package.
Can we disable some rules like 'Document all public members' ?

I'm not sure if this was missed or not in scope of the project but would you consider adding it?

https://dart.dev/guides/language/effective-dart/documentation#do-format-comments-like-sentences

Thank you

I wan to suggest to add the following rules to the effective dart analysis options:

• avoid_void_async
• await_only_futures

I find these lint rules extremely important as the helped me to find and avoid multiple issues in cases where you simply forget to add the async keyword to a method definition and try to await the result, although the method isn't really executed asynchronously. I can not think of a case where it would be reasonable to omit these rules.

After approval of dart-lang/site-www#2193, add avoid_equals_and_hash_code_on_mutable_classes.

I think we could disable omit_local_variable_types by default.

At the moment, below code will cause a warning

User user = repo.getUser();

But this one will not:

var user = repo.getUser();

However, User user = ... will make code easy to understand, and if anyone needs to view User source code, he can press Ctrl and click on User to navigate to User class.
I believe after compiling, such var will be replaced by the correct type (User).

Thus, I think we should disable omit_local_variable_types by default.

Please feel free to direct me to a better suited place for this! I did not find any other place for discussion on these guidelines. (SO maybe?)

The public_member_api_docs also applies to constructors. What use is a "Creates an instance of this class" docstring, really? Especially for parameterless constructors that are just performing initializion etc.?

After approval of dart-lang/site-www#2186, add camel_case_extensions.

After approval of dart-lang/site-www#2188, add prefer_relative_imports.

We should discuss what we want to do with this package.

We have essentially two options:

1. provide all the lints (which works) according to Effective Dart & users can suppress alone what they don't want to follow and to follow.
2. suppress some rules because there are some use cases which might not work for some people & users can turn them on alone (that, unfortunately, puts some additional knowledge on users)

What would be best?

This also covers issues #3 and #4.

I kinda like the first way, so the package attempts more to comply with all the guide rules. And this package is about that after all. The second way provides a more general package, but steps back from the Effective Dart in some way.

Let me know what do you think!

It would be nice, since we collect lints manually, to create some easy script, which would create us the output list of lints. The script should generate similar style to the existing one.

Additionally, we also might add ignored lints option, so the script would comment those. (we might create file with ignore rules; as e.g. tool/ignored-lints.yaml).

Also, the script should output "no diff" or generate new file.

For pages:

• https://dart.dev/guides/language/effective-dart/style
• https://dart.dev/guides/language/effective-dart/documentation
• https://dart.dev/guides/language/effective-dart/usage
• https://dart.dev/guides/language/effective-dart/design

The script may be saved as tool/collect.sh file.

Hi,
How can I set files to ignoring?
I have generated code (intl), and I don't want notifications about that. "Exclude" parameter doesn't work.

After approval of dart-lang/site-www#2192, add avoid_types_on_closure_parameters.

After approval of dart-lang/site-www#2191, add prefer_mixin.

The dry run didn't catch this issue. Make at least one character longer description. 🤷‍♂

I have to figure out how to change it. Any suggestions would be welcome.

dart-lang/linter#2029