Terser statements (from review comments)

ksunden · ksunden · commit c898957e0ddf · 2023-01-26T13:43:25.000-06:00
diff --git a/doc/api/next_api_changes/development/24893-KS.rst b/doc/api/next_api_changes/development/24893-KS.rst
@@ -5,11 +5,4 @@ The maximum line length for new contributions has been extended from 79 characte
 88 characters.
 This change provides an extra 9 characters to allow code which is a single idea to fit
 on fewer lines (often a single line).
-Other line lengths considered included 115 and 99, but ultimately 88 characters was the
-consensus as it is relatively conservative while still providing reasonable benefit.
-The ability to view side-by-side git diffs was a key point in choosing the smaller
-limit.
-Additionally, it is easier to increase the line length again than to decrease it if it
-was found too large.
 The chosen length is the same as `black <https://black.readthedocs.io/en/stable/the_black_code_style/current_style.html#line-length>`_.
-Their justifications influenced the discussion and provided a standard value.
diff --git a/doc/devel/coding_guide.rst b/doc/devel/coding_guide.rst
@@ -157,11 +157,10 @@ Content topics:
 * Does the PR conform with the :ref:`coding_guidelines`?
 * Is the :ref:`documentation <pr-documentation>` (docstrings, examples,
   what's new, API changes) updated?
-* Is the change only reflowing code/docstrings for increased line length?
-  Generally, such changes are discouraged when not part of other non-stylistic
-  work because it obscures the git history of functional changes to the code.
-  Reflowing a method or docstring as part of a larger refactor/rewrite is
-  acceptable.
+* Is the change purely stylistic? Generally, such changes are discouraged when
+  not part of other non-stylistic work because it obscures the git history of
+  functional changes to the code. Reflowing a method or docstring as part of a
+  larger refactor/rewrite is acceptable.
 
 
 Organizational topics:
