Apply suggestions from code review

Co-authored-by: Jelle Zijlstra <jelle.zijlstra@gmail.com>
Signed-off-by: RedGuy12 <61329810+RedGuy12@users.noreply.github.com>

docs/faq.md

@@ -79,6 +79,7 @@ following will not be formatted:
 
 ## Why does Flake8 report warnings?
 
+Some of Flake8's rules conflict with Black's style. We recommend disabling these rules.
 See [Using _Black_ with other tools](labels/why-pycodestyle-warnings).
 
 ## Which Python versions does Black support?

docs/guides/using_black_with_other_tools.md

@@ -167,9 +167,9 @@ should be disabled.
 ##### `E701` / `E704`
 
 _Black_ will collapse implementations of classes and functions consisting solely of
-"..." or "pass" on to a single line. This matches how such examples are formatted in
-PEP 8. It remains true that in all other cases Black will prevent multiple statements on
-the same line, in accordance with PEP 8 generally discouraging this.
+"..." or "pass" to a single line. This matches how such examples are formatted in PEP 8.
+It remains true that in all other cases Black will prevent multiple statements on the
+same line, in accordance with PEP 8 generally discouraging this.
 
 However, `pycodestyle` does not mirror this logic and may raise
 `E701 multiple statements on one line (colon)` in this situation. Its
@@ -183,7 +183,7 @@ with PEP 8 as of
 [April 2016](https://github.com/python/peps/commit/c59c4376ad233a62ca4b3a6060c81368bd21e85b#diff-64ec08cc46db7540f18f2af46037f599).
 There's a disabled-by-default warning in Flake8 which goes against this PEP 8
 recommendation called `W503 line break before binary operator`. It should not be enabled
-in your configuration. You should use its counterpart
+in your configuration. You can use its counterpart
 `W504 line break after binary operator` instead.
 
 #### Formats
@@ -207,7 +207,7 @@ pycodestyle. As such, it has many of the same issues.
 #### Bugbear
 
 It's recommended to use [the Bugbear plugin](https://github.com/PyCQA/flake8-bugbear)
-and enabling
+and enable
 [its B950 check](https://github.com/PyCQA/flake8-bugbear#opinionated-warnings#:~:text=you%20expect%20it.-,B950,-%3A%20Line%20too%20long)
 instead of using Flake8's E501, because it aligns with
 [Black's 10% rule](labels/line-length).

docs/the_black_code_style/current_style.md

@@ -143,21 +143,20 @@ significantly shorter files than sticking with 80 (the most popular), or even 79
 by the standard library). In general,
 [90-ish seems like the wise choice](https://youtu.be/wf-BqAjZb8M?t=260).
 
-If you're paid by the number of lines of code you write, you can pass `--line-length`
-with a lower number. _Black_ will try to respect that. However, sometimes it won't be
-able to without breaking other rules. In those rare cases, auto-formatted code will
-exceed your allotted limit.
+If you're paid by the lines of code you write, you can pass `--line-length` with a lower
+number. _Black_ will try to respect that. However, sometimes it won't be able to without
+breaking other rules. In those rare cases, auto-formatted code will exceed your allotted
+limit.
 
 You can also increase it, but remember that people with sight disabilities find it
 harder to work with line lengths exceeding 100 characters. It also adversely affects
 side-by-side diff review on typical screen resolutions. Long lines also make it harder
 to present code neatly in documentation or talk slides.
 
-#### Flake8 / pycodestyle
+#### Flake8 and other linters
 
-See
-[Using _Black_ with other tools](../guides/using_black_with_other_tools.md#pycodestyle)
-about linter compatibility.
+See [Using _Black_ with other tools](../guides/using_black_with_other_tools.md) about
+linter compatibility.
 
 ### Empty lines