-
Notifications
You must be signed in to change notification settings - Fork 1.7k
tool for machine-format lint listing #58280
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Labels
devexp-linter
Issues with the analyzer's support for the linter package
legacy-area-analyzer
Use area-devexp instead.
type-documentation
A request to add or improve documentation
type-enhancement
A request for a change that isn't a bug
Comments
Sample (abbreviated) output: [
{
"name": "always_use_package_imports",
"description": "Avoid relative imports for files in `lib/`.",
"group": "errors",
"details": "*DO* avoid relative imports for files in `lib/`.\n\nWhen mixing relative and absolute imports it's possible to create confusion\nwhere the same member gets imported in two different ways. One way to avoid\nthat is to ensure you consistently use absolute imports for files withing the\n`lib/` directory.\n\nThis is the opposite of 'prefer_relative_imports'.\nMight be used with 'avoid_relative_lib_imports' to avoid relative imports of\nfiles within `lib/` directory outside of it. (for example `test/`)\n\n**GOOD:**\n\n```\nimport 'package:foo/bar.dart';\n\nimport 'package:foo/baz.dart';\n\nimport 'package:foo/src/baz.dart';\n...\n```\n\n**BAD:**\n\n```\nimport 'baz.dart';\n\nimport 'src/bag.dart'\n\nimport '../lib/baz.dart';\n\n...\n```\n\n"
},
{
"name": "avoid_empty_else",
"description": "Avoid empty else statements.",
"group": "errors",
"details": "\n**AVOID** empty else statements.\n\n**BAD:**\n```\nif (x > y)\n print(\"1\");\nelse ;\n print(\"2\");\n```\n\n"
},
{
"name": "avoid_print",
"description": "Avoid `print` calls in production code.",
"group": "errors",
"details": "**DO** avoid `print` calls in production code.\n\n**BAD:**\n```\nvoid f(int x) {\n print('debug: $x');\n ...\n}\n```\n"
}
]``` |
That depends. What is the purpose or motivation for this work? |
A first cut of a listing is now being produced as part of our docgen and lives here: |
This is finished. Refinements tracked in new issues. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
devexp-linter
Issues with the analyzer's support for the linter package
legacy-area-analyzer
Use area-devexp instead.
type-documentation
A request to add or improve documentation
type-enhancement
A request for a change that isn't a bug
dart-archive/linter#2358 introduces a simple tool to generate a JSON dump of rules. Now what?
Should this output be committed? Should this tool get run as part of the CI? Should we add more data (e.g., rule set inclusions, like "pedantic"?)
/cc @csells @devoncarew @bwilkerson
The text was updated successfully, but these errors were encountered: