tenhobi / effective_dart Goto Github PK
View Code? Open in Web Editor NEWLinter rules corresponding to the guidelines in Effective Dart
Home Page: https://pub.dev/packages/effective_dart
License: MIT License
Linter rules corresponding to the guidelines in Effective Dart
Home Page: https://pub.dev/packages/effective_dart
License: MIT License
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:
The script may be saved as tool/collect.sh
file.
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.
New badge markdown:
[![style: effective dart](https://img.shields.io/badge/style-effective_dart-40c4ff.svg)](https://pub.dev/packages/effective_dart)
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.
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. :)
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
I wan to suggest to add the following rules to the effective dart analysis options:
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#2186, add camel_case_extensions
.
Hi!
Looking at advice for imports, it looks like we're suggesting conflicting rules:
effective_dart/lib/analysis_options.1.2.0.yaml
Lines 23 to 24 in 7a3e4a8
Or maybe the docs need to be updated?
After approval of dart-lang/site-www#2188, add prefer_relative_imports
.
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#2192, add avoid_types_on_closure_parameters
.
Add badge to all lints used by package:effective_dart
on page http://dart-lang.github.io/linter/lints/.
That would probably include changing files:
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.
as for the title, please consider adding the experimental lint avoid_dynamic_calls
thank you
Thanks for this cool package.
Can we disable some rules like 'Document all public members' ?
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).
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?
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
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?
We should discuss what we want to do with this package.
We have essentially two options:
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!
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
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.
After approval of dart-lang/site-www#2190, add avoid_catching_errors
.
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.
After approval of dart-lang/site-www#2191, add prefer_mixin
.
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 do
s and don't
s and don't fail for prefer
s and avoid
s.
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. 🤷♂️
error
for do
s and don't
s, or it's too hard? Should I use warning
for that?error
will be used for do
s and don't
s, then warning
for prefer
s and avoid
s and info
for consider
s?consider
s 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 consider
s?I would like some comments, mostly to be as aligned as possible with the guide intention.
Maybe cc @pq @kwalrath ...
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.
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
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!
After approval of dart-lang/site-www#2193, add avoid_equals_and_hash_code_on_mutable_classes
.
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.
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.?
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.