[clang-tidy] update readability-* and zircon-* check documentation to remove extraneous characters

[MyDeveloperDay]

Summary

Using new tool developed as part of D55523: [clang-tidy] Linting .rst documentation, update existing readability-* and zircon-* documentation with the results of validate_check.py -check_all findings

• removal of double spaces
• removal of trailing whitespaces
• removal of blank lines at the end of file
• removal of double blank adjacent lines
• maximize 80 chars per line

[MyDeveloperDay]

I thought I would just correct readability-* and zircon-* to get some feedback if you think this is improving the documentation the way you think it should, if this is OK I can follow up with the other checks (not sure if they are better in separate commits or all together)

[JonasToth]

In D55594#1328061, @MyDeveloperDay wrote:

I thought I would just correct readability-* and zircon-* to get some feedback if you think this is improving the documentation the way you think it should, if this is OK I can follow up with the other checks (not sure if they are better in separate commits or all together)

Sounds, good. I would honestly even wait until we settle on the validate_check and then merge theses improvements, too.
In general what I see here looks good :)

[Eugene.Zelenko]

Looks OK for me, but I agree with Jonas, it's better to commit changes made with final version.

docs/clang-tidy/checks/readability-uppercase-literal-suffix.rst

6

Should be separate statement. Was mistake in original documentation.

docs/clang-tidy/checks/readability-const-return-type.rst

 .. title:: clang-tidy - readability-const-return-type
 
 readability-const-return-type
 =============================
 
 Checks for functions with a ``const``-qualified return type and recommends
 removal of the ``const`` keyword. Such use of `const` is usually superfluous,
-and can prevent valuable compiler optimizations.  Does not (yet) fix trailing
+and can prevent valuable compiler optimizations. Does not (yet) fix trailing
 return types.
 
 Examples:
 
 .. code-block:: c++
-    
   const int foo();
   const Clazz foo();
   Clazz *const foo();
 
 Note that this applies strictly to top-level qualification, which excludes
 pointers or references to const values. For example, these are fine:
 
 .. code-block:: c++
 
    const int* foo();
    const int& foo();
    const Clazz* foo();

docs/clang-tidy/checks/readability-container-size-empty.rst

 .. title:: clang-tidy - readability-container-size-empty
 
 readability-container-size-empty
 ================================
 
-
 Checks whether a call to the ``size()`` method can be replaced with a call to
 ``empty()``.
 
 The emptiness of a container should be checked using the ``empty()`` method
 instead of the ``size()`` method. It is not guaranteed that ``size()`` is a
 constant-time function, and it is generally more efficient and also shows
 clearer intent to use ``empty()``. Furthermore some containers may implement
 the ``empty()`` method but not implement the ``size()`` method. Using

docs/clang-tidy/checks/readability-delete-null-pointer.rst

 .. title:: clang-tidy - readability-delete-null-pointer
 
 readability-delete-null-pointer
 ===============================
 
-Checks the ``if`` statements where a pointer's existence is checked and then deletes the pointer.
-The check is unnecessary as deleting a null pointer has no effect.
+Checks the ``if`` statements where a pointer's existence is checked and then
+deletes the pointer. The check is unnecessary as deleting a null pointer has no
+effect.
 
 .. code:: c++
 
   int *p;
   if (p)
     delete p;

docs/clang-tidy/checks/readability-else-after-return.rst

void foo(int Value) {
         if (Value == 3) {
           throw 42;
         } else {
           Local++;
         }
       }
     }
 
-
 Would be transformed into:
 
 .. code-block:: c++
 
     void foo(int Value) {
       int Local = 0;
       for (int i = 0; i < 42; i++) {
         if (Value == 1) {
           return;
         }
         Local++;
 
         if (Value == 2)
           continue;
         Local++;
 
         if (Value == 3) {
           throw 42;
         }
         Local++;
       }
     }
 
-
 This check helps to enforce this `LLVM Coding Standards recommendation
 <http://llvm.org/docs/CodingStandards.html#don-t-use-else-after-a-return>`_.

docs/clang-tidy/checks/readability-identifier-naming.rst

 .. title:: clang-tidy - readability-identifier-naming
 
 readability-identifier-naming
 =============================
 
 Checks for identifiers naming style mismatch.
 
-This check will try to enforce coding guidelines on the identifiers naming.
-It supports `lower_case`, `UPPER_CASE`, `camelBack` and `CamelCase` casing and
+This check will try to enforce coding guidelines on the identifiers naming. It
+supports `lower_case`, `UPPER_CASE`, `camelBack` and `CamelCase` casing and
 tries to convert from one to another if a mismatch is detected.
 
-It also supports a fixed prefix and suffix that will be prepended or
-appended to the identifiers, regardless of the casing.
+It also supports a fixed prefix and suffix that will be prepended or appended
+to the identifiers, regardless of the casing.
 
 Many configuration options are available, in order to be able to create
-different rules for different kind of identifier. In general, the
-rules are falling back to a more generic rule if the specific case is not
-configured.
+different rules for different kind of identifier. In general, the rules are
+falling back to a more generic rule if the specific case is not configured.

docs/clang-tidy/checks/readability-implicit-bool-conversion.rst

 .. title:: clang-tidy - readability-implicit-bool-conversion
 
 readability-implicit-bool-conversion
 ====================================
 
 This check can be used to find implicit conversions between built-in types and
-booleans. Depending on use case, it may simply help with readability of the code,
-or in some cases, point to potential bugs which remain unnoticed due to implicit
-conversions.
+booleans. Depending on use case, it may simply help with readability of the
+code, or in some cases, point to potential bugs which remain unnoticed due to
+implicit conversions.
 
 The following is a real-world example of bug which was hiding behind implicit
 ``bool`` conversion:
 
 .. code-block:: c++
 
   class Foo {
     int m_foo;

docs/clang-tidy/checks/readability-isolate-declaration.rst

 .. title:: clang-tidy - readability-isolate-declaration
 
 readability-isolate-declaration
 ===============================
 
-Detects local variable declarations declaring more than one variable and
-tries to refactor the code to one statement per declaration.
+Detects local variable declarations declaring more than one variable and tries
+to refactor the code to one statement per declaration.
 
 The automatic code-transformation will use the same indentation as the original
-for every created statement and add a line break after each statement.
-It keeps the order of the variable declarations consistent, too.
+for every created statement and add a line break after each statement. It keeps
+the order of the variable declarations consistent, too.
 
 .. code-block:: c++
 
   void f() {
     int * pointer = nullptr, value = 42, * const const_ptr = &value;
     // This declaration will be diagnosed and transformed into:
     // int * pointer = nullptr;
     // int value = 42;
     // int * const const_ptr = &value;
   }
 
-
 The check excludes places where it is necessary or common to declare
 multiple variables in one statement and there is no other way supported in the
 language. Please note that structured bindings are not considered.
 
 .. code-block:: c++
 
   // It is not possible to transform this declaration and doing the declaration
   // before the loop will increase the scope of the variable 'Begin' and 'End'
   // which is undesirable.
   for (int Begin = 0, End = 100; Begin < End; ++Begin);
   if (int Begin = 42, Result = some_function(Begin); Begin == Result);
 
   // It is not possible to transform this declaration because the result is
   // not functionality preserving as 'j' and 'k' would not be part of the
   // 'if' statement anymore.
   if (SomeCondition())
     int i = 42, j = 43, k = function(i,j);
 
-
 Limitations
 -----------
 
 Global variables and member variables are excluded.
 
 The check currently does not support the automatic transformation of
 member-pointer-types.
 

docs/clang-tidy/checks/readability-magic-numbers.rst

constants to improve readability. Here are a few references:
    * Item 17 in "C++ Coding Standards: 101 Rules, Guidelines and Best
      Practices" by Herb Sutter and Andrei Alexandrescu
    * Chapter 17 in "Clean Code - A handbook of agile software craftsmanship."
      by Robert C. Martin
    * Rule 20701 in "TRAIN REAL TIME DATA PROTOCOL Coding Rules" by Armin-Hagen
      Weiss, Bombardier
    * http://wiki.c2.com/?MagicNumber
 
-
 Examples of magic values:
 
 .. code-block:: c++
 
    double circleArea = 3.1415926535 * radius * radius;
 
    double totalCharge = 1.08 * itemPrice;
 
.. option:: IgnoredFloatingPointValues
    Semicolon-separated list of magic positive floating point values that will
    be accepted without a warning. Default values are `{1.0, 100.0}` and `0.0`
    is accepted unconditionally.
 
 .. option:: IgnoreAllFloatingPointValues
 
    Boolean value indicating whether to accept all floating point values without
    warning. Default value is `false`.
-

docs/clang-tidy/checks/readability-misleading-indentation.rst

 .. title:: clang-tidy - readability-misleading-indentation
 
 readability-misleading-indentation
 ==================================
 
 Correct indentation helps to understand code. Mismatch of the syntactical
-structure and the indentation of the code may hide serious problems.
-Missing braces can also make it significantly harder to read the code,
-therefore it is important to use braces. 
+structure and the indentation of the code may hide serious problems. Missing
+braces can also make it significantly harder to read the code, therefore it is
+important to use braces.
 
-The way to avoid dangling else is to always check that an ``else`` belongs
-to the ``if`` that begins in the same column.
+The way to avoid dangling else is to always check that an ``else`` belongs to
+the ``if`` that begins in the same column.
 
 You can omit braces when your inner part of e.g. an ``if`` statement has only
 one statement in it. Although in that case you should begin the next statement
 in the same column with the ``if``.
 
 Examples:
 
 .. code-block:: c++

docs/clang-tidy/checks/readability-misplaced-array-index.rst

.. code-block:: c++
 
   void f(int *X, int Y) {
     X[Y] = 0;
   }
 
 The check warns about such unusual syntax for readability reasons:
  * There are programmers that are not familiar with this unusual syntax.
  * It is possible that variables are mixed up.
-

docs/clang-tidy/checks/readability-redundant-smartptr-get.rst

 .. title:: clang-tidy - readability-redundant-smartptr-get
 
 readability-redundant-smartptr-get
 ==================================
 
 Find and remove redundant calls to smart pointer's ``.get()`` method.
 
 Examples:
 
 .. code-block:: c++
 
   ptr.get()->Foo()  ==>  ptr->Foo()
   *ptr.get()  ==>  *ptr
   *ptr->get()  ==>  **ptr
   if (ptr.get() == nullptr) ... => if (ptr == nullptr) ...
 
-
 .. option:: IgnoreMacros
 
    If this option is set to non-zero (default is `1`), the check will not warn
    about calls inside macros.

docs/clang-tidy/checks/readability-redundant-string-cstr.rst

 .. title:: clang-tidy - readability-redundant-string-cstr
 
 readability-redundant-string-cstr
 =================================
 
-
 Finds unnecessary calls to ``std::string::c_str()`` and ``std::string::data()``.

docs/clang-tidy/checks/readability-simplify-boolean-expr.rst

 .. title:: clang-tidy - readability-simplify-boolean-expr
 
 readability-simplify-boolean-expr
 =================================
 
-Looks for boolean expressions involving boolean constants and simplifies
-them to use the appropriate boolean expression directly.
+Looks for boolean expressions involving boolean constants and simplifies them
+to use the appropriate boolean expression directly.
 
 Examples:
 
 ===========================================  ================
 Initial expression                           Result
 -------------------------------------------  ----------------
 ``if (b == true)``                             ``if (b)``
 ``if (b == false)``                            ``if (!b)``

docs/clang-tidy/checks/readability-static-accessed-through-instance.rst

 
 is changed to:
 
 .. code-block:: c++
 
   C *c1 = new C();
   C::foo();
   C::x;
-

docs/clang-tidy/checks/readability-string-compare.rst

 .. title:: clang-tidy - readability-string-compare
 
 readability-string-compare
 ==========================
 
 Finds string comparisons using the compare method.
 
-A common mistake is to use the string's ``compare`` method instead of using the 
+A common mistake is to use the string's ``compare`` method instead of using the
 equality or inequality operators. The compare method is intended for sorting
-functions and thus returns a negative number, a positive number or 
-zero depending on the lexicographical relationship between the strings compared. 
-If an equality or inequality check can suffice, that is recommended. This is 
+functions and thus returns a negative number, a positive number or zero
+depending on the lexicographical relationship between the strings compared. If
+an equality or inequality check can suffice, that is recommended. This is
 recommended to avoid the risk of incorrect interpretation of the return value
-and to simplify the code. The string equality and inequality operators can
-also be faster than the ``compare`` method due to early termination.
+and to simplify the code. The string equality and inequality operators can also
+be faster than the ``compare`` method due to early termination.
 
 Examples:
 
 .. code-block:: c++
 
   std::string str1{"a"};
   std::string str2{"b"};
 
.. code-block:: c++
   if (0 != str1.compare(str2)) {
   }
 
   // Use str1 == "foo" instead.
   if (str1.compare("foo") == 0) {
   }
 
 The above code examples shows the list of if-statements that this check will
-give a warning for. All of them uses ``compare`` to check if equality or 
+give a warning for. All of them uses ``compare`` to check if equality or
 inequality of two strings instead of using the correct operators.

docs/clang-tidy/checks/readability-uniqueptr-delete-release.rst

 .. title:: clang-tidy - readability-uniqueptr-delete-release
 
 readability-uniqueptr-delete-release
 ====================================
 
-Replace ``delete <unique_ptr>.release()`` with ``<unique_ptr> = nullptr``.
-The latter is shorter, simpler and does not require use of raw pointer APIs.
+Replace ``delete <unique_ptr>.release()`` with ``<unique_ptr> = nullptr``. The
+latter is shorter, simpler and does not require use of raw pointer APIs.
 
 .. code-block:: c++
 
   std::unique_ptr<int> P;
   delete P.release();
 
   // becomes
 
   std::unique_ptr<int> P;
   P = nullptr;

docs/clang-tidy/checks/readability-uppercase-literal-suffix.rst

 .. title:: clang-tidy - readability-uppercase-literal-suffix
 
 readability-uppercase-literal-suffix
 ====================================
 
-`cert-dcl16-c` redirects here as an alias for this check.
-By default, only the suffixes that begin with ``l`` (``l``, ``ll``, ``lu``,
-``llu``, but not ``u``, ``ul``, ``ull``) are diagnosed by that alias.
+`cert-dcl16-c` redirects here as an alias for this check. By default, only the
+suffixes that begin with ``l`` (``l``, ``ll``, ``lu``, ``llu``, but not ``u``,
+``ul``, ``ull``) are diagnosed by that alias.
 
 `hicpp-uppercase-literal-suffix` redirects here as an alias for this check.
 
 Detects when the integral literal or floating point (decimal or hexadecimal)
 literal has a non-uppercase suffix and provides a fix-it hint with the uppercase
 suffix.
 
 All valid combinations of suffixes are supported.

docs/clang-tidy/checks/zircon-temporary-objects.rst

 .. title:: clang-tidy - zircon-temporary-objects
 
 zircon-temporary-objects
 ========================
 
-Warns on construction of specific temporary objects in the Zircon kernel. 
-If the object should be flagged, If the object should be flagged, the fully 
+Warns on construction of specific temporary objects in the Zircon kernel. If
+the object should be flagged, If the object should be flagged, the fully
 qualified type name must be explicitly passed to the check.
 
-For example, given the list of classes "Foo" and "NS::Bar", all of the 
-following will trigger the warning: 
+For example, given the list of classes "Foo" and "NS::Bar", all of the
+following will trigger the warning:
 
 .. code-block:: c++
 
   Foo();
   Foo F = Foo();
   func(Foo());
 
   namespace NS {
 
   Bar();
 
   }
 
 With the same list, the following will not trigger the warning:
 
 .. code-block:: c++
 
   Foo F;                 // Non-temporary construction okay
   Foo F(param);          // Non-temporary construction okay
   Foo *F = new Foo();    // New construction okay
 
   Bar();                 // Not NS::Bar, so okay
   NS::Bar B;             // Non-temporary construction okay
 
-Note that objects must be explicitly specified in order to be flagged, 
-and so objects that inherit a specified object will not be flagged.
+Note that objects must be explicitly specified in order to be flagged, and so
+objects that inherit a specified object will not be flagged.
 
 This check matches temporary objects without regard for inheritance and so a
 prohibited base class type does not similarly prohibit derived class types.
 
 .. code-block:: c++
 
   class Derived : Foo {} // Derived is not explicitly disallowed
   Derived();             // and so temporary construction is okay
 
 Options
 -------
 
 .. option:: Names
 
-   A semi-colon-separated list of fully-qualified names of C++ classes that 
+   A semi-colon-separated list of fully-qualified names of C++ classes that
    should not be constructed as temporaries. Default is empty.