Put enforced lints just in yaml file, not enforced lints just in README.md.
diff --git a/README.md b/README.md
index f45d6fb..184a8da 100644
--- a/README.md
+++ b/README.md
@@ -30,46 +30,36 @@
- Lints are considered and enabled on a case by case basis. When enabling a
lint we first clean up all pre-existing violations. After it's enabled, any
attempt to check in a further violation will be blocked.
+
+## Enabled Lints
-The currently enabled lints are:
+The currently enabled lints can be found in the sample
+[analysis_options.yaml](https://github.com/dart-lang/pedantic/blob/master/analysis_options.yaml).
-```yaml
-linter:
- rules:
- - avoid_empty_else
- - avoid_return_types_on_setters
- - avoid_types_as_parameter_names
- - control_flow_in_finally
- - no_duplicate_case_values
- - prefer_contains
- - prefer_equal_for_default_values
- - prefer_is_not_empty
- - recursive_getters
- - throw_in_finally
- - unrelated_type_equality_checks
- - use_rethrow_when_possible
- - valid_regexps
-```
+## Unused Lints
The following lints have been considered and will _not_ be enforced:
-```yaml
-# always_put_control_body_on_new_line
-# Violates Effective Dart "DO format your code using dartfmt". See note
-# about Flutter SDK style below.
-# always_specify_types
-# Violates Effective Dart "AVOID type annotating initialized local
-# variables" and others. See note about Flutter SDK style below.
-# avoid_as
-# Does not reflect standard usage. See note about Flutter SDK style below.
-# empty_statements
-# Enforcing use of dartfmt is sufficient to make empty statements obvious.
-# Also, see linter issue #383 for discussion of false positives.
-# prefer_bool_in_asserts
-# Obsolete in Dart 2; bool is required in asserts.
-# prefer_final_locals
-# Does not reflect standard usage.
-```
+`always_put_control_body_on_new_line`
+violates Effective Dart "DO format your code using dartfmt". See note about
+Flutter SDK style below.
+
+`always_specify_types`
+violates Effective Dart "AVOID type annotating initialized local variables"
+and others. See note about Flutter SDK style below.
+
+`avoid_as`
+does not reflect standard usage. See note about Flutter SDK style below.
+
+`empty_statements`
+is superfluous, enforcing use of `dartfmt` is sufficient to make empty
+ statements obvious.
+
+`prefer_bool_in_asserts`
+ is obsolete in Dart 2; bool is required in asserts.
+
+`prefer_final_locals`
+does not reflect standard usage.
Note on Flutter SDK Style: some lints were created specifically to support
Flutter SDK development. Flutter app developers should instead use standard
diff --git a/analysis_options.yaml b/analysis_options.yaml
index 386721f..1844c97 100644
--- a/analysis_options.yaml
+++ b/analysis_options.yaml
@@ -2,11 +2,8 @@
# for details. All rights reserved. Use of this source code is governed by a
# BSD-style license that can be found in the LICENSE file.
#
-# Google internally enforced rules.
-#
-# This is a living document that will evolve over time.
-#
-# Copy and modify as you see fit!
+# Google internally enforced rules. See README.md for more information,
+# including a list of lints that are intentionally _not_ enforced.
linter:
rules:
@@ -24,25 +21,3 @@
- unrelated_type_equality_checks
- use_rethrow_when_possible
- valid_regexps
-
-# The following lints will NOT be enforced for google internal code.
-#
-# always_put_control_body_on_new_line
-# Violates Effective Dart "DO format your code using dartfmt". See note
-# about Flutter SDK style below.
-# always_specify_types
-# Violates Effective Dart "AVOID type annotating initialized local
-# variables" and others. See note about Flutter SDK style below.
-# avoid_as
-# Does not reflect standard usage. See note about Flutter SDK style below.
-# empty_statements
-# Enforcing use of dartfmt is sufficient to make empty statements obvious.
-# Also, see linter issue #383 for discussion of false positives.
-# prefer_bool_in_asserts
-# Obsolete in Dart 2; bool is required in asserts.
-# prefer_final_locals
-# Does not reflect standard usage.
-#
-# Note on Flutter SDK Style: some lints were created specifically to support
-# Flutter SDK development. Flutter app developers should instead use standard
-# Dart style as described in Effective Dart, and should not use these lints.
