SONARPY-3753 Update RSPEC before 5.18 release (#868)

GitOrigin-RevId: 8d44684a869ce9601dfe0f9fc03882af9f5536b7

Author: thomas-serre-sonarsource

python-checks/src/main/resources/org/sonar/l10n/py/rules/python/ExecStatementUsage.html

@@ -4,13 +4,13 @@ <h2>Why is this an issue?</h2>
 3.0. Instead, the built-in <code>exec()</code> function can be used.</p>
 <p>Use of the <code>exec</code> statement is strongly discouraged for several reasons such as:</p>
 <ul>
-  <li> <strong>Security Risks:</strong> Executing code from a string opens up the possibility of code injection attacks. </li>
-  <li> <strong>Readability and Maintainability:</strong> Code executed with <code>exec</code> statement is often harder to read and understand since
-  it is not explicitly written in the source code. </li>
-  <li> <strong>Performance Implications:</strong> The use of <code>exec</code> statement can have performance implications since the code is compiled
-  and executed at runtime. </li>
-  <li> <strong>Limited Static Analysis:</strong> Since the code executed with <code>exec</code> statement is only known at runtime, static code
-  analysis tools may not be able to catch certain errors or issues, leading to potential bugs. </li>
+  <li><strong>Security Risks:</strong> Executing code from a string opens up the possibility of code injection attacks.</li>
+  <li><strong>Readability and Maintainability:</strong> Code executed with <code>exec</code> statement is often harder to read and understand since it
+  is not explicitly written in the source code.</li>
+  <li><strong>Performance Implications:</strong> The use of <code>exec</code> statement can have performance implications since the code is compiled
+  and executed at runtime.</li>
+  <li><strong>Limited Static Analysis:</strong> Since the code executed with <code>exec</code> statement is only known at runtime, static code
+  analysis tools may not be able to catch certain errors or issues, leading to potential bugs.</li>
 </ul>
 <h3>Code examples</h3>
 <h4>Noncompliant code example</h4>

python-checks/src/main/resources/org/sonar/l10n/py/rules/python/InequalityUsage.html

@@ -14,6 +14,6 @@ <h4>Compliant solution</h4>
 <h2>Resources</h2>
 <h3>Documentation</h3>
 <ul>
-  <li> Python Documentation: <a href="https://docs.python.org/2.7/reference/lexical_analysis.html#operators">Python 2.7 - Operators</a> </li>
+  <li>Python Documentation: <a href="https://docs.python.org/2.7/reference/lexical_analysis.html#operators">Python 2.7 - Operators</a></li>
 </ul>
 

python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S101.html

@@ -29,7 +29,7 @@ <h2>Why is this an issue?</h2>
 <h2>Resources</h2>
 <h3>Documentation</h3>
 <ul>
-  <li> <a href="https://peps.python.org/pep-0008/#class-names">PEP 8 – Style Guide for Python Code</a> </li>
-  <li> <a href="https://en.wikipedia.org/wiki/Snake_case">Wikipedia: Snake case</a> </li>
+  <li><a href="https://peps.python.org/pep-0008/#class-names">PEP 8 – Style Guide for Python Code</a></li>
+  <li><a href="https://en.wikipedia.org/wiki/Snake_case">Wikipedia: Snake case</a></li>
 </ul>
 

python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S1045.html

@@ -3,22 +3,22 @@ <h2>Why is this an issue?</h2>
 <p>Exceptions handlers (<code>except</code>) are evaluated in the order they are written. Once a match is found, the evaluation stops.</p>
 <p>In some contexts, an except block is dead code as it will never catch any exception:</p>
 <ul>
-  <li> If there is a handler for a base class followed by a handler for class derived from that base class, the second handler will never trigger: The
-  handler for the base class will match the derived class, and will be the only executed handler. </li>
-  <li> When multiple <code>except</code> statements try to catch the same exception class, only the first one will be executed. </li>
-  <li> In Python 3, <code>BaseException</code> is the parent of every exception class. When a <code>BaseException</code> is caught by an
+  <li>If there is a handler for a base class followed by a handler for class derived from that base class, the second handler will never trigger: The
+  handler for the base class will match the derived class, and will be the only executed handler.</li>
+  <li>When multiple <code>except</code> statements try to catch the same exception class, only the first one will be executed.</li>
+  <li>In Python 3, <code>BaseException</code> is the parent of every exception class. When a <code>BaseException</code> is caught by an
   <code>except</code> clause, none of the subsequent <code>except</code> statement will catch anything. This is true as well for the bare except
-  statement (<code>except:</code>). </li>
+  statement (<code>except:</code>).</li>
 </ul>
 <h2>How to fix it</h2>
 <p>When using multiple <code>except</code> statements, make sure to:</p>
 <ul>
-  <li> Order the <code>except</code> blocks from the most specialzed exception to the most generic, i.e when wanting to catch a
+  <li>Order the <code>except</code> blocks from the most specialzed exception to the most generic, i.e when wanting to catch a
   <code>FloatingPointError</code> and an <code>ArithemticError</code>, as <code>FloatingPointError</code> is a subclass of
-  <code>ArithmeticError</code>, the first <code>except</code> statement should be <code>FloatingPointError</code>. </li>
-  <li> Catch the same exception only once. </li>
-  <li> Catch a <code>BaseException</code> only once with either an <code>except BaseException:</code> statement or a bare <code>except:</code>
-  statement, as the two statements are equivalent. </li>
+  <code>ArithmeticError</code>, the first <code>except</code> statement should be <code>FloatingPointError</code>.</li>
+  <li>Catch the same exception only once.</li>
+  <li>Catch a <code>BaseException</code> only once with either an <code>except BaseException:</code> statement or a bare <code>except:</code>
+  statement, as the two statements are equivalent.</li>
 </ul>
 <h3>Code examples</h3>
 <h4>Noncompliant code example</h4>
@@ -75,7 +75,7 @@ <h4>Compliant solution</h4>
 <h2>Resources</h2>
 <h3>Documentation</h3>
 <ul>
-  <li> <a href="https://docs.python.org/3/reference/compound_stmts.html#the-try-statement">The <code>try</code> statement</a> </li>
-  <li> <a href="https://docs.python.org/3/library/exceptions.html#exception-hierarchy">Exception hierarchy</a> </li>
+  <li><a href="https://docs.python.org/3/reference/compound_stmts.html#the-try-statement">The <code>try</code> statement</a></li>
+  <li><a href="https://docs.python.org/3/library/exceptions.html#exception-hierarchy">Exception hierarchy</a></li>
 </ul>
 

python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S107.html

@@ -7,7 +7,7 @@ <h2>Why is this an issue?</h2>
 </pre>
 <p>The solution can be to:</p>
 <ul>
-  <li> Split the function, method, or lambda into smaller ones </li>
+  <li>Split the function, method, or lambda into smaller ones</li>
 </ul>
 <pre>
 # Each function does a part of what the original set_coordinates function was doing, so confusion risks are lower
@@ -18,7 +18,7 @@ <h2>Why is this an issue?</h2>
    # ...
 </pre>
 <ul>
-  <li> Find a better data structure for the parameters that group data in a way that makes sense for the specific application domain </li>
+  <li>Find a better data structure for the parameters that group data in a way that makes sense for the specific application domain</li>
 </ul>
 <pre>
 @dataclass

python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S112.html

@@ -14,9 +14,9 @@ <h2>Why is this an issue?</h2>
 <h2>How to fix it</h2>
 <p>To fix this issue, make sure to throw specific exceptions that are relevant to the context in which they arise. It is recommended to either:</p>
 <ul>
-  <li> Raise a specific <a href="https://docs.python.org/3/library/exceptions.html">Built-in exception</a> when one matches. For example
-  <code>TypeError</code> should be raised when the type of a parameter is not the one expected. </li>
-  <li> Create a custom exception class deriving from <code>Exception</code> or one of its subclasses. </li>
+  <li>Raise a specific <a href="https://docs.python.org/3/library/exceptions.html">Built-in exception</a> when one matches. For example
+  <code>TypeError</code> should be raised when the type of a parameter is not the one expected.</li>
+  <li>Create a custom exception class deriving from <code>Exception</code> or one of its subclasses.</li>
 </ul>
 <h3>Code examples</h3>
 <h4>Noncompliant code example</h4>
@@ -34,7 +34,7 @@ <h4>Compliant solution</h4>
 <h2>Resources</h2>
 <h3>Documentation</h3>
 <ul>
-  <li> Python Documentation - <a href="https://docs.python.org/3/library/exceptions.html#BaseException">Built-in exceptions</a> </li>
-  <li> PEP 352 - <a href="https://www.python.org/dev/peps/pep-0352/#exception-hierarchy-changes">Required Superclass for Exceptions</a> </li>
+  <li>Python Documentation - <a href="https://docs.python.org/3/library/exceptions.html#BaseException">Built-in exceptions</a></li>
+  <li>PEP 352 - <a href="https://www.python.org/dev/peps/pep-0352/#exception-hierarchy-changes">Required Superclass for Exceptions</a></li>
 </ul>
 

python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S1134.html

@@ -9,6 +9,6 @@ <h2>Why is this an issue?</h2>
 <h2>Resources</h2>
 <h3>Documentation</h3>
 <ul>
-  <li> CWE - <a href="https://cwe.mitre.org/data/definitions/546">CWE-546 - Suspicious Comment</a> </li>
+  <li>CWE - <a href="https://cwe.mitre.org/data/definitions/546">CWE-546 - Suspicious Comment</a></li>
 </ul>
 

python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S1135.html

@@ -22,6 +22,6 @@ <h3>Noncompliant code example</h3>
 </pre>
 <h2>Resources</h2>
 <ul>
-  <li> CWE - <a href="https://cwe.mitre.org/data/definitions/546">CWE-546 - Suspicious Comment</a> </li>
+  <li>CWE - <a href="https://cwe.mitre.org/data/definitions/546">CWE-546 - Suspicious Comment</a></li>
 </ul>
 

python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S1143.html

@@ -104,6 +104,6 @@ <h3>Compliant solution</h3>
 </pre>
 <h2>Resources</h2>
 <ul>
-  <li> Python documentation - <a href="https://docs.python.org/3/reference/compound_stmts.html#except">the <code>try</code> statement</a> </li>
+  <li>Python documentation - <a href="https://docs.python.org/3/reference/compound_stmts.html#except">the <code>try</code> statement</a></li>
 </ul>
 

python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S1144.html

@@ -5,13 +5,13 @@ <h2>Why is this an issue?</h2>
 <p>Python has no real private methods. Every method is accessible. There are however two conventions indicating that a method is not meant to be
 "public":</p>
 <ul>
-  <li> methods with a name starting with a single underscore (ex: <code>_mymethod</code>) should be seen as non-public and might change without prior
+  <li>methods with a name starting with a single underscore (ex: <code>_mymethod</code>) should be seen as non-public and might change without prior
   notice. They should not be used by third-party libraries or software. It is ok to use those methods inside the library defining them but it should
-  be done with caution. </li>
-  <li> "class-private" methods have a name which starts with at least two underscores and ends with at most one underscore. These methods' names will
+  be done with caution.</li>
+  <li>"class-private" methods have a name which starts with at least two underscores and ends with at most one underscore. These methods' names will
   be automatically mangled to avoid collision with subclasses' methods. For example <code>__mymethod</code> will be renamed as
   <code>_classname__mymethod</code>, where <code>classname</code> is the method’s class name without its leading underscore(s). These methods
-  shouldn’t be used outside of their enclosing class. </li>
+  shouldn’t be used outside of their enclosing class.</li>
 </ul>
 <p>This rule raises an issue when a class-private method (two leading underscores, max one underscore at the end) is never called inside the class.
 Class methods, static methods and instance methods will all raise an issue.</p>
@@ -53,7 +53,7 @@ <h4>Compliant solution</h4>
 </pre>
 <h2>Resources</h2>
 <ul>
-  <li> <a href="https://docs.python.org/3.8/tutorial/classes.html#private-variables">Python documentation – Private Variables</a> </li>
-  <li> <a href="https://www.python.org/dev/peps/pep-0008/#designing-for-inheritance">PEP8 – Designing for Inheritance</a> </li>
+  <li><a href="https://docs.python.org/3.8/tutorial/classes.html#private-variables">Python documentation – Private Variables</a></li>
+  <li><a href="https://www.python.org/dev/peps/pep-0008/#designing-for-inheritance">PEP8 – Designing for Inheritance</a></li>
 </ul>