From cbda7304ea2baf4ab491777866ee7247a741f910 Mon Sep 17 00:00:00 2001
From: David Kunzmann <david.kunzmann@sonarsource.com>
Date: Wed, 1 Nov 2023 13:57:17 +0100
Subject: [PATCH] Updated rules metadata (#1629)

---
 .../org/sonar/l10n/py/rules/python/S1066.html |  30 ++++-
 .../org/sonar/l10n/py/rules/python/S1066.json |   2 +-
 .../org/sonar/l10n/py/rules/python/S1110.html |   8 +-
 .../org/sonar/l10n/py/rules/python/S112.html  | 104 ++++-----------
 .../org/sonar/l10n/py/rules/python/S1128.json |   2 +-
 .../org/sonar/l10n/py/rules/python/S113.json  |   2 +-
 .../org/sonar/l10n/py/rules/python/S1131.html |   7 +-
 .../org/sonar/l10n/py/rules/python/S1135.html |   2 +-
 .../org/sonar/l10n/py/rules/python/S1144.html |  11 +-
 .../org/sonar/l10n/py/rules/python/S1144.json |   2 +-
 .../org/sonar/l10n/py/rules/python/S116.html  |  21 ++-
 .../org/sonar/l10n/py/rules/python/S117.html  |  65 ++++++++-
 .../org/sonar/l10n/py/rules/python/S1172.html |  35 +++--
 .../org/sonar/l10n/py/rules/python/S1186.html |  70 +++++-----
 .../org/sonar/l10n/py/rules/python/S1192.html |  45 ++++---
 .../org/sonar/l10n/py/rules/python/S125.html  |   5 +-
 .../org/sonar/l10n/py/rules/python/S134.html  |  48 +++++--
 .../org/sonar/l10n/py/rules/python/S1481.html |  51 ++++---
 .../org/sonar/l10n/py/rules/python/S1854.html |  34 +++--
 .../org/sonar/l10n/py/rules/python/S1854.json |   2 +-
 .../org/sonar/l10n/py/rules/python/S1871.html |  23 +++-
 .../org/sonar/l10n/py/rules/python/S2068.html |   1 -
 .../org/sonar/l10n/py/rules/python/S2077.html |   1 -
 .../org/sonar/l10n/py/rules/python/S2092.html |   1 -
 .../org/sonar/l10n/py/rules/python/S2208.html |  30 +++--
 .../org/sonar/l10n/py/rules/python/S2257.html |   1 -
 .../org/sonar/l10n/py/rules/python/S2612.html |   1 -
 .../org/sonar/l10n/py/rules/python/S3330.html |   1 -
 .../org/sonar/l10n/py/rules/python/S3457.html |  34 +++--
 .../org/sonar/l10n/py/rules/python/S3457.json |   2 +-
 .../org/sonar/l10n/py/rules/python/S3752.html |   1 -
 .../org/sonar/l10n/py/rules/python/S3776.html | 126 +++++++++++++++++-
 .../org/sonar/l10n/py/rules/python/S3776.json |   2 +-
 .../org/sonar/l10n/py/rules/python/S4423.html |   1 -
 .../org/sonar/l10n/py/rules/python/S4502.html |   1 -
 .../org/sonar/l10n/py/rules/python/S4721.html |   1 -
 .../org/sonar/l10n/py/rules/python/S4787.html |   1 -
 .../org/sonar/l10n/py/rules/python/S4790.html |   1 -
 .../org/sonar/l10n/py/rules/python/S4792.html |   1 -
 .../org/sonar/l10n/py/rules/python/S4823.html |   1 -
 .../org/sonar/l10n/py/rules/python/S4830.html |  61 +++++++++
 .../org/sonar/l10n/py/rules/python/S5122.html |   1 -
 .../org/sonar/l10n/py/rules/python/S5300.html |   1 -
 .../org/sonar/l10n/py/rules/python/S5439.html |   1 -
 .../org/sonar/l10n/py/rules/python/S5542.html |   1 -
 .../org/sonar/l10n/py/rules/python/S5547.html |   1 -
 .../org/sonar/l10n/py/rules/python/S6353.html |  28 ++--
 .../org/sonar/l10n/py/rules/python/S6554.html |  12 +-
 .../org/sonar/l10n/py/rules/python/S6559.html |  10 +-
 .../org/sonar/l10n/py/rules/python/S6660.html |   4 +-
 .../org/sonar/l10n/py/rules/python/S6660.json |   8 +-
 .../org/sonar/l10n/py/rules/python/S6799.html |  20 +--
 .../org/sonar/l10n/py/rules/python/S6799.json |   2 +-
 .../org/sonar/l10n/py/rules/python/S905.html  |  55 ++++++--
 sonarpedia.json                               |   2 +-
 55 files changed, 654 insertions(+), 330 deletions(-)

diff --git a/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S1066.html b/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S1066.html
index c74ce7bf70..2f56c6021f 100644
--- a/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S1066.html
+++ b/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S1066.html
@@ -1,14 +1,34 @@
 <h2>Why is this an issue?</h2>
-<p>Merging collapsible <code>if</code> statements increases the code’s readability.</p>
-<h3>Noncompliant code example</h3>
+<p>Nested code - blocks of code inside blocks of code - is eventually necessary, but increases complexity. This is why keeping the code as flat as
+possible, by avoiding unnecessary nesting, is considered a good practice.</p>
+<p>Merging <code>if</code> statements when possible will decrease the nesting of the code and improve its readability.</p>
+<p>Code like</p>
 <pre>
 if condition1:
-    if condition2:
+    if condition2:             # Noncompliant
         # ...
 </pre>
-<h3>Compliant solution</h3>
+<p>Will be more readable as</p>
 <pre>
-if condition1 and condition2:
+if condition1 and condition2:  # Compliant
     # ...
 </pre>
+<h2>How to fix it</h2>
+<p>If merging the conditions seems to result in a more complex code, extracting the condition or part of it in a named function or variable is a
+better approach to fix readability.</p>
+<h3>Code examples</h3>
+<h4>Noncompliant code example</h4>
+<pre>
+if file.isValid():
+  if file.isfile() or file.isdir():     # Noncompliant
+    # ...
+</pre>
+<h4>Compliant solution</h4>
+<pre>
+def isFileOrDirectory(File file):
+  return file.isFile() or file.isDirectory()
+
+if file.isValid() and isFileOrDirectory(file): # Compliant
+  # ...
+</pre>
 
diff --git a/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S1066.json b/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S1066.json
index f6857be37a..732a6ea96f 100644
--- a/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S1066.json
+++ b/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S1066.json
@@ -1,5 +1,5 @@
 {
-  "title": "Collapsible \"if\" statements should be merged",
+  "title": "Mergeable \"if\" statements should be combined",
   "type": "CODE_SMELL",
   "code": {
     "impacts": {
diff --git a/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S1110.html b/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S1110.html
index 64880ce03a..30ee967061 100644
--- a/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S1110.html
+++ b/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S1110.html
@@ -1,6 +1,10 @@
 <h2>Why is this an issue?</h2>
-<p>The use of parentheses, even those not required to enforce a desired order of operations, can clarify the intent behind a piece of code. But
-redundant pairs of parentheses could be misleading, and should be removed.</p>
+<p>Parentheses can disambiguate the order of operations in complex expressions and make the code easier to understand.</p>
+<pre>
+a = (b * c) + (d * e) # Compliant: the intent is clear.
+</pre>
+<p>Redundant parentheses are parenthesis that do not change the behavior of the code, and do not clarify the intent. They can mislead and complexify
+the code. They should be removed.</p>
 <h3>Noncompliant code example</h3>
 <pre>
 return ((3))        # Noncompliant
diff --git a/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S112.html b/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S112.html
index 74a133d401..3238a11f21 100644
--- a/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S112.html
+++ b/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S112.html
@@ -1,92 +1,40 @@
+<p>This rule raises an issue when a generic exception (such as <code>Exception</code> or <code>BaseException</code>) is raised.</p>
 <h2>Why is this an issue?</h2>
 <p>Raising instances of <a href="https://docs.python.org/3/library/exceptions.html#Exception"><code>Exception</code></a> and <a
 href="https://docs.python.org/3/library/exceptions.html#BaseException"><code>BaseException</code></a> will have a negative impact on any code trying
 to catch these exceptions.</p>
-<p>First, the only way to handle differently multiple Exceptions is to check their message, which is error-prone and difficult to maintain.</p>
-<p>What’s more, it becomes difficult to catch only your exception. The best practice is to catch only exceptions which require a specific handling.
-When you raise <code>Exception</code> or <code>BaseException</code> in a function the caller will have to add an <code>except Exception</code> or
-<code>except BaseException</code> and re-raise all exceptions which were unintentionally caught. This can create tricky bugs when the caller forgets
-to re-raise exceptions such as <code>SystemExit</code> and the software cannot be stopped.</p>
-<p>It is recommended to either:</p>
+<p>From a consumer perspective, it is generally a best practice to only catch exceptions you intend to handle. Other exceptions should ideally not be
+caught and let to propagate up the stack trace so that they can be dealt with appropriately. When a generic exception is thrown, it forces consumers
+to catch exceptions they do not intend to handle, which they then have to re-raise.</p>
+<p>Besides, when working with a generic type of exception, the only way to distinguish between multiple exceptions is to check their message, which is
+error-prone and difficult to maintain. Legitimate exceptions may be unintentionally silenced and errors may be hidden.</p>
+<p>For instance, if an exception such as <code>SystemExit</code> is caught and not re-raised, it will prevent the program from stopping.</p>
+<p>When raising an exception, it is therefore recommended to raising the most specific exception possible so that it can be handled intentionally by
+consumers.</p>
+<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 more specific <a href="https://docs.python.org/3/library/exceptions.html">Built-in exception</a> when one matches. For example
+  <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. A common practice for libraries is to have one
-  custom root exception class from which every other custom exception class inherits. It enables other projects using this library to catch all errors
-  coming from the library with a single "except" statement </li>
+  <li> Create a custom exception class deriving from <code>Exception</code> or one of its subclasses. </li>
 </ul>
-<p>This rule raises an issue when <code>Exception</code> or <code>BaseException</code> are raised.</p>
-<h3>Noncompliant code example</h3>
-<pre>
-def process1():
-    raise BaseException("Wrong user input for field X")  # Noncompliant
-
-def process2():
-    raise BaseException("Wrong configuration")  # Noncompliant
-
-def process3(param):
-    if not isinstance(param, int):
-        raise Exception("param should be an integer")  # Noncompliant
-
-def caller():
-    try:
-         process1()
-         process2()
-         process3()
-    except BaseException as e:
-        if e.args[0] == "Wrong user input for field X":
-            # process error
-            pass
-        elif e.args[0] == "Wrong configuration":
-            # process error
-            pass
-        else:
-            # re-raise other exceptions
-            raise
+<h3>Code examples</h3>
+<h4>Noncompliant code example</h4>
+<pre data-diff-id="1" data-diff-type="noncompliant">
+def check_value(value):
+    if value &lt; 0:
+        raise BaseException("Value cannot be negative") # Noncompliant: this will be difficult for consumers to handle
 </pre>
-<h3>Compliant solution</h3>
-<pre>
-class MyProjectError(Exception):
-    """Exception class from which every exception in this library will derive.
-         It enables other projects using this library to catch all errors coming
-         from the library with a single "except" statement
-    """
-    pass
-
-class BadUserInputError(MyProjectError):
-    """A specific error"""
-    pass
-
-class ConfigurationError(MyProjectError):
-    """A specific error"""
-    pass
-
-def process1():
-    raise BadUserInputError("Wrong user input for field X")
-
-def process2():
-    raise ConfigurationError("Wrong configuration")
-
-def process3(param):
-    if not isinstance(param, int):
-        raise TypeError("param should be an integer")
-
-def caller():
-    try:
-         process1()
-         process2()
-         process3()
-    except BadUserInputError as e:
-        # process error
-        pass
-    except ConfigurationError as e:
-        # process error
-        pass
+<h4>Compliant solution</h4>
+<pre data-diff-id="1" data-diff-type="compliant">
+def check_value(value):
+    if value &lt; 0:
+        raise ValueError("Value cannot be negative") # Compliant
 </pre>
 <h2>Resources</h2>
+<h3>Documentation</h3>
 <ul>
-  <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> <a href="https://cwe.mitre.org/data/definitions/397">MITRE, CWE-397</a> - Declaration of Throws for Generic Exception </li>
+  <li> PEP 352 - <a href="https://www.python.org/dev/peps/pep-0352/#exception-hierarchy-changes">Required Superclass for Exceptions</a> </li>
 </ul>
 
diff --git a/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S1128.json b/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S1128.json
index d3ad8e74ad..1b4b7b19be 100644
--- a/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S1128.json
+++ b/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S1128.json
@@ -10,7 +10,7 @@
   "status": "ready",
   "remediation": {
     "func": "Constant\/Issue",
-    "constantCost": "2min"
+    "constantCost": "1min"
   },
   "tags": [
     "unused"
diff --git a/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S113.json b/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S113.json
index b5acb1513c..1d0fcfdd81 100644
--- a/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S113.json
+++ b/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S113.json
@@ -1,5 +1,5 @@
 {
-  "title": "Files should contain an empty newline at the end",
+  "title": "Files should end with a newline",
   "type": "CODE_SMELL",
   "code": {
     "impacts": {
diff --git a/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S1131.html b/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S1131.html
index a5cab54ce8..625feb7197 100644
--- a/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S1131.html
+++ b/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S1131.html
@@ -1,6 +1,5 @@
 <h2>Why is this an issue?</h2>
-<p>Trailing whitespaces are simply useless and should not stay in code. They may generate noise when comparing different versions of the same
-file.</p>
-<p>If you encounter issues from this rule, this probably means that you are not using an automated code formatter - which you should if you have the
-opportunity to do so.</p>
+<p>Trailing whitespaces bring no information, they may generate noise when comparing different versions of the same file, and they can create bugs
+when they appear after a <code>\</code> marking a line continuation. They should be systematically removed.</p>
+<p>An automated code formatter allows to completely avoid this family of issues and should be used wherever possible.</p>
 
diff --git a/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S1135.html b/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S1135.html
index a1e46710a4..ac5c06060a 100644
--- a/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S1135.html
+++ b/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S1135.html
@@ -1,5 +1,5 @@
 <h2>Why is this an issue?</h2>
-<p>Developers often use <code>TOOO</code> tags to mark areas in the code where additional work or improvements are needed but are not implemented
+<p>Developers often use <code>TODO</code> tags to mark areas in the code where additional work or improvements are needed but are not implemented
 immediately. However, these <code>TODO</code> tags sometimes get overlooked or forgotten, leading to incomplete or unfinished code. This code smell
 class aims to identify and address such unattended <code>TODO</code> tags to ensure a clean and maintainable codebase. This description will explore
 why this is a problem and how it can be fixed to improve the overall code quality.</p>
diff --git a/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S1144.html b/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S1144.html
index fe68bc77a0..5f77d996a3 100644
--- a/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S1144.html
+++ b/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S1144.html
@@ -1,7 +1,7 @@
+<p>This rule raises an issue when a "class-private" method is never called inside the class where it was declared.</p>
 <h2>Why is this an issue?</h2>
-<p>"Class-Private" methods that are never executed inside their enclosing class are dead code: unnecessary, inoperative code that should be removed.
-Cleaning out dead code decreases the size of the maintained codebase, making it easier to understand the program and preventing bugs from being
-introduced.</p>
+<p>A method that is never called is dead code, and should be removed. Cleaning out dead code decreases the size of the maintained codebase, making it
+easier to understand the program and preventing bugs from being introduced.</p>
 <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>
@@ -15,7 +15,8 @@ <h2>Why is this an issue?</h2>
 </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>
-<h3>Noncompliant code example</h3>
+<h3>Code examples</h3>
+<h4>Noncompliant code example</h4>
 <pre>
 class Noncompliant:
 
@@ -30,7 +31,7 @@ <h3>Noncompliant code example</h3>
     def __mangled_instance_method(self):  # Noncompliant
         print("__mangled_instance_method")
 </pre>
-<h3>Compliant solution</h3>
+<h4>Compliant solution</h4>
 <pre>
 class Compliant:
 
diff --git a/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S1144.json b/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S1144.json
index 410bf119ad..cb1030c681 100644
--- a/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S1144.json
+++ b/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S1144.json
@@ -10,7 +10,7 @@
   "status": "ready",
   "remediation": {
     "func": "Constant\/Issue",
-    "constantCost": "5min"
+    "constantCost": "2min"
   },
   "tags": [
     "unused"
diff --git a/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S116.html b/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S116.html
index 0ceccb315d..887bf086cf 100644
--- a/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S116.html
+++ b/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S116.html
@@ -1,15 +1,22 @@
 <h2>Why is this an issue?</h2>
-<p>Sharing some naming conventions is a key point to make it possible for a team to efficiently collaborate. This rule allows to check that field
-names match a provided regular expression.</p>
-<h3>Noncompliant code example</h3>
-<p>With the default regular expression <code>^[_a-z][_a-z0-9]*$</code>:</p>
-<pre>
+<p>A naming convention in software development is a set of guidelines for naming code elements like variables, functions, and classes.</p>
+<p>The goal of a naming convention is to make the code more readable and understandable, which makes it easier to maintain and debug. It also ensures
+consistency in the code, especially when multiple developers are working on the same project.</p>
+<p>This rule checks that field names match a provided regular expression.</p>
+<p>Using the regular expression <code>^[_a-z][_a-z0-9]*$</code>, the noncompliant code below:</p>
+<pre data-diff-id="1" data-diff-type="noncompliant">
 class MyClass:
   myField = 1
 </pre>
-<h3>Compliant solution</h3>
-<pre>
+<p>Should be replaced with:</p>
+<pre data-diff-id="1" data-diff-type="compliant">
 class MyClass:
   my_field = 1
 </pre>
+<h2>Resources</h2>
+<h3>Documentation</h3>
+<ul>
+  <li> Python Enhancement Proposals - <a href="https://peps.python.org/pep-0008/#naming-conventions">PEP8 - Naming Conventions</a> </li>
+  <li> Wikipedia - <a href="https://en.wikipedia.org/wiki/Naming_convention_(programming)">Naming Convention (programming)</a> </li>
+</ul>
 
diff --git a/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S117.html b/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S117.html
index 980292a638..fa242cf94b 100644
--- a/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S117.html
+++ b/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S117.html
@@ -1,10 +1,69 @@
+<p>Local variables and function parameters should be named consistently to communicate intent and improve maintainability. Rename your local variable
+or function parameter to follow your project’s naming convention to address this issue.</p>
 <h2>Why is this an issue?</h2>
-<p>Shared naming conventions allow teams to collaborate effectively. This rule raises an issue when a local variable or function parameter name does
-not match the provided regular expression.</p>
+<p>A naming convention in software development is a set of guidelines for naming code elements like variables, functions, and classes.<br> Local
+variables and function parameters hold the meaning of the written code. Their names should be meaningful and follow a consistent and easily
+recognizable pattern.<br> Adhering to a consistent naming convention helps to make the code more readable and understandable, which makes it easier to
+maintain and debug. It also ensures consistency in the code, especially when multiple developers are working on the same project.</p>
+<p>This rule checks that local variable and function parameter names match a provided regular expression.</p>
+<h3>What is the potential impact?</h3>
+<p>Inconsistent naming of local variables and function parameters can lead to several issues in your code:</p>
+<ul>
+  <li> Reduced Readability: inconsistent local variable and function parameter names make the code harder to read and understand; consequently, it is
+  more difficult to identify the purpose of each variable, spot errors, or comprehend the logic. </li>
+  <li> Difficulty in Identifying Variables: local variables and function parameters that don’t adhere to a standard naming convention are challenging
+  to identify; thus, the coding process slows down, especially when dealing with a large codebase. </li>
+  <li> Increased Risk of Errors: inconsistent or unclear local variable and function parameter names lead to misunderstandings about what the variable
+  represents. This ambiguity leads to incorrect assumptions and, consequently, bugs in the code. </li>
+  <li> Collaboration Difficulties: in a team setting, inconsistent naming conventions lead to confusion and miscommunication among team members. </li>
+  <li> Difficulty in Code Maintenance: inconsistent naming leads to an inconsistent codebase. The code is difficult to understand, and making changes
+  feels like refactoring constantly, as you face different naming methods. Ultimately, it makes the codebase harder to maintain. </li>
+</ul>
+<p>In summary, not adhering to a naming convention for local variables and function parameters can lead to confusion, errors, and inefficiencies,
+making the code harder to read, understand, and maintain.</p>
 <h3>Exceptions</h3>
-<p>Loop counters are ignored by this rule.</p>
+<p>Loop counters of one letter are ignored by this rule.</p>
 <pre>
 for i in range(limit):  # Compliant
     print(i)
 </pre>
+<p>Local variables matching regular expression <code>^[_A-Z][A-Z0-9_]*$</code> are considered as constant and ignored by this rule.<br> Function
+parameters are not concerned by this exception.</p>
+<pre>
+def print_something(important_param):
+    LOCAL_VARIABLE = "" # Compliant
+    print(important_param + LOCAL_VARIABLE)
+</pre>
+<h2>How to fix it</h2>
+<p>First, familiarize yourself with the particular naming convention of the project in question. Then, update the name to match the convention, as
+well as all usages of the name. For many IDEs, you can use built-in renaming and refactoring features to update all usages at once.</p>
+<h3>Code examples</h3>
+<h4>Noncompliant code example</h4>
+<p>With the default regular expression <code>^[_a-z][a-z0-9_]*$</code>:</p>
+<pre data-diff-id="1" data-diff-type="noncompliant">
+def print_something(IMPORTANT_PARAM): # Noncompliant
+    localVariable = "" # Noncompliant
+    print(IMPORTANT_PARAM + localVariable)
+</pre>
+<h4>Compliant solution</h4>
+<pre data-diff-id="1" data-diff-type="compliant">
+def print_something(important_param):
+    local_variable = ""
+    print(important_param + local_variable)
+</pre>
+<h2>Resources</h2>
+<h3>Documentation</h3>
+<ul>
+  <li> Python Enhancement Proposals - <a href="https://peps.python.org/pep-0008/#naming-conventions">PEP8 - Naming Conventions</a> </li>
+  <li> Wikipedia - <a href="https://en.wikipedia.org/wiki/Naming_convention_(programming)">Naming Convention (programming)</a> </li>
+</ul>
+<h3>Related rules</h3>
+<ul>
+  <li> {rule:python:S100} - Method names should comply with a naming convention </li>
+  <li> {rule:python:S101} - Class names should comply with a naming convention </li>
+  <li> {rule:python:S116} - Field names should comply with a naming convention </li>
+  <li> {rule:python:S1542} - Function names should comply with a naming convention </li>
+  <li> {rule:python:S1578} - Module names should comply with a naming convention </li>
+  <li> {rule:python:S2710} - The first argument to class methods should follow the naming convention </li>
+</ul>
 
diff --git a/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S1172.html b/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S1172.html
index a856614221..b4d799df66 100644
--- a/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S1172.html
+++ b/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S1172.html
@@ -1,26 +1,33 @@
 <h2>Why is this an issue?</h2>
-<p>Unused parameters are misleading. Whatever the value passed to such parameters is, the behavior will be the same.</p>
-<h3>Noncompliant code example</h3>
-<pre>
-def do_something(a, b): # "b" is unused
-  return compute(a)
-</pre>
-<h3>Compliant solution</h3>
-<pre>
-def do_something(a):
-  return compute(a)
-</pre>
+<p>A typical code smell known as unused function parameters refers to parameters declared in a function but not used anywhere within the function’s
+body. While this might seem harmless at first glance, it can lead to confusion and potential errors in your code. Disregarding the values passed to
+such parameters, the function’s behavior will be the same, but the programmer’s intention won’t be clearly expressed anymore. Therefore, removing
+function parameters that are not being utilized is considered best practice.</p>
 <h3>Exceptions</h3>
-<p>Overriding methods are ignored.</p>
+<p>This rule ignores overriding methods.</p>
 <pre>
 class C(B):
   def do_something(self, a, b): # no issue reported on b
     return self.compute(a)
-}
 </pre>
-<p>Throwaway variables <code>_</code>.</p>
+<p>This rule also ignores variables named with a single underscore <code>_</code>. Such naming is a common practice for indicating that the variable
+is insignificant.</p>
 <pre>
 def do_something(a, _): # no issue reported on _
   return compute(a)
 </pre>
+<h2>How to fix it</h2>
+<p>Having unused function parameters in your code can lead to confusion and misunderstanding of a developer’s intention. They reduce code readability
+and introduce the potential for errors. To avoid these problems, developers should remove unused parameters from function declarations.</p>
+<h3>Code examples</h3>
+<h4>Noncompliant code example</h4>
+<pre data-diff-id="1" data-diff-type="noncompliant">
+def do_something(a, b): # "b" is unused
+  return compute(a)
+</pre>
+<h4>Compliant solution</h4>
+<pre data-diff-id="1" data-diff-type="compliant">
+def do_something(a):
+  return compute(a)
+</pre>
 
diff --git a/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S1186.html b/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S1186.html
index 2eec141fe3..a15334ba69 100644
--- a/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S1186.html
+++ b/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S1186.html
@@ -1,47 +1,14 @@
 <h2>Why is this an issue?</h2>
-<p>There are several reasons for a function or a method not to have a body:</p>
+<p>An empty method is generally considered bad practice and can lead to confusion, readability, and maintenance issues. Empty methods bring no
+functionality and are misleading to others as they might think the method implementation fulfills a specific and identified requirement.</p>
+<p>There are several reasons for a method not to have a body:</p>
 <ul>
   <li> It is an unintentional omission, and should be fixed to prevent an unexpected behavior in production. </li>
   <li> It is not yet, or never will be, supported. In this case an exception should be thrown. </li>
   <li> The method is an intentionally-blank override. In this case a nested comment should explain the reason for the blank override. </li>
 </ul>
-<h3>Noncompliant code example</h3>
-<pre>
-def myfunc1(foo="Noncompliant"):
-    pass
-
-class MyClass:
-    def mymethod1(self, foo="Noncompliant"):
-        pass
-</pre>
-<h3>Compliant solution</h3>
-<pre>
-def myfunc1():
-    pass  # comment explaining why this function is empty
-
-def myfunc2():
-    raise NotImplementedError()
-
-def myfunc3():
-    """
-    Docstring explaining why this function is empty.
-    """
-
-class MyClass:
-    def mymethod1(self):
-        pass  # comment explaining why this function is empty
-
-    def mymethod2(self):
-        raise NotImplementedError()
-
-    def mymethod3(self):
-        """
-        Docstring explaining why this method is empty. Note that this is not recommended for classes
-        which are meant to be subclassed.
-        """
-</pre>
 <h3>Exceptions</h3>
-<p>No issue will be raised when the empty method is abstract and meant to be overriden in a subclass, i.e. it is decorated with
+<p>No issue will be raised when the empty method is abstract and meant to be overridden in a subclass, i.e. it is decorated with
 <code>abc.abstractmethod</code>, <code>abc.abstractstaticmethod</code>, <code>abc.abstractclassmethod</code> or <code>abc.abstractproperty</code>.
 Note however that these methods should normally have a docstring explaining how subclasses should implement these methods.</p>
 <pre>
@@ -64,4 +31,33 @@ <h3>Exceptions</h3>
     def mystaticmethod():
         pass
 </pre>
+<h2>How to fix it</h2>
+<h3>Code examples</h3>
+<h4>Noncompliant code example</h4>
+<pre data-diff-id="1" data-diff-type="noncompliant">
+def shouldNotBeEmpty():  # Noncompliant - method is empty
+    pass
+
+def notImplemented():  # Noncompliant - method is empty
+    pass
+
+def emptyOnPurpose():  # Noncompliant - method is empty
+    pass
+</pre>
+<h4>Compliant solution</h4>
+<pre data-diff-id="1" data-diff-type="compliant">
+def shouldNotBeEmpty():
+    doSomething()
+
+def notImplemented():
+    raise NotImplementedError("notImplemented() cannot be performed because ...")
+
+def emptyOnPurpose():
+    pass  # comment explaining why the method is empty
+
+def emptyOnPurposeBis():
+    """
+    Docstring explaining why this function is empty.
+    """
+</pre>
 
diff --git a/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S1192.html b/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S1192.html
index 40cc968e87..082f477fae 100644
--- a/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S1192.html
+++ b/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S1192.html
@@ -1,23 +1,6 @@
 <h2>Why is this an issue?</h2>
-<p>Duplicated string literals make the process of refactoring error-prone, since you must be sure to update all occurrences.</p>
-<p>On the other hand, constants can be referenced from many places, but only need to be updated in a single place.</p>
-<h3>Noncompliant code example</h3>
-<p>With the default threshold of 3:</p>
-<pre>
-def run():
-    prepare("this is a duplicate")  # Noncompliant - "this is a duplicate" is duplicated 3 times
-    execute("this is a duplicate")
-    release("this is a duplicate")
-</pre>
-<h3>Compliant solution</h3>
-<pre>
-ACTION_1 = "action1"
-
-def run():
-    prepare(ACTION_1)
-    execute(ACTION_1)
-    release(ACTION_1)
-</pre>
+<p>Duplicated string literals make the process of refactoring complex and error-prone, as any change would need to be propagated on all
+occurrences.</p>
 <h3>Exceptions</h3>
 <p>No issue will be raised on:</p>
 <ul>
@@ -25,13 +8,33 @@ <h3>Exceptions</h3>
   <li> strings with less than 5 characters </li>
   <li> strings with only letters, numbers and underscores </li>
 </ul>
-<pre>
+<h2>How to fix it</h2>
+<p>Instead, use constants to replace the duplicated string literals. Constants can be referenced from many places, but only need to be updated in a
+single place.</p>
+<h3>Code examples</h3>
+<h4>Noncompliant code example</h4>
+<p>With the default threshold of 3:</p>
+<pre data-diff-id="1" data-diff-type="noncompliant">
+def run():
+    prepare("action1")  # Noncompliant - "action1" is duplicated 3 times
+    execute("action1")
+    release("action1")
+
 @app.route("/api/users/", methods=['GET', 'POST', 'PUT'])
 def users():
     pass
 
-@app.route("/api/projects/", methods=['GET', 'POST', 'PUT'])  # Compliant
+@app.route("/api/projects/", methods=['GET', 'POST', 'PUT'])  # Compliant - strings inside decorators are ignored
 def projects():
     pass
 </pre>
+<h4>Compliant solution</h4>
+<pre data-diff-id="1" data-diff-type="compliant">
+ACTION_1 = "action1"
+
+def run():
+    prepare(ACTION_1)
+    execute(ACTION_1)
+    release(ACTION_1)
+</pre>
 
diff --git a/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S125.html b/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S125.html
index 86475f084c..0d83de02ce 100644
--- a/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S125.html
+++ b/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S125.html
@@ -1,4 +1,5 @@
 <h2>Why is this an issue?</h2>
-<p>Programmers should not comment out code as it bloats programs and reduces readability.</p>
-<p>Unused code should be deleted and can be retrieved from source control history if required.</p>
+<p>Commented-out code distracts the focus from the actual executed code. It creates a noise that increases maintenance code. And because it is never
+executed, it quickly becomes out of date and invalid.</p>
+<p>Commented-out code should be deleted and can be retrieved from source control history if required.</p>
 
diff --git a/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S134.html b/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S134.html
index 4bd6913ef1..d1b75a1869 100644
--- a/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S134.html
+++ b/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S134.html
@@ -1,17 +1,43 @@
 <h2>Why is this an issue?</h2>
-<p>Nested <code>if</code>, <code>for</code>, <code>while</code>, <code>try</code>, and <code>with</code> statements are key ingredients for making
-what’s known as "Spaghetti code". Such code is hard to read, refactor and therefore maintain.</p>
-<h3>Noncompliant code example</h3>
-<p>The following code snippet illustrates this rule with the default threshold of 3.</p>
-<pre>
-  if condition1:           # Compliant - depth = 1
+<p>Nested control flow statements <code>if</code>, <code>for</code>, <code>while</code>, <code>try</code>, and <code>with</code> are often key
+ingredients in creating what’s known as "Spaghetti code". This code smell can make your program difficult to understand and maintain.</p>
+<p>When numerous control structures are placed inside one another, the code becomes a tangled, complex web. This significantly reduces the code’s
+readability and maintainability, and it also complicates the testing process.</p>
+<h2>How to fix it</h2>
+<h3>Code examples</h3>
+<p>The following example demonstrates the behavior of the rule with the default threshold of 4 levels of nesting and one of the potential ways to fix
+the code smell by introducing guard clauses:</p>
+<h4>Noncompliant code example</h4>
+<pre data-diff-id="1" data-diff-type="noncompliant">
+if condition1:           # Compliant - depth = 1
+  # ...
+  if condition2:         # Compliant - depth = 2
     # ...
-    if condition2:         # Compliant - depth = 2
+    for i in range(10):  # Compliant - depth = 3
       # ...
-      for i in range(10):  # Compliant - depth = 3, not exceeding the limit
-        # ...
-        if condition4:     # Non-Compliant - depth = 4
-          if condition5:   # Depth = 5, exceeding the limit, but issues are only reported on depth = 4
+      if condition3:     # Compliant - depth = 4
+        if condition4:     # Non-Compliant - depth = 5, which exceeds the limit
+          if condition5:   # Depth = 6, exceeding the limit, but issues are only reported on depth = 5
             # ...
 </pre>
+<h4>Compliant solution</h4>
+<pre data-diff-id="1" data-diff-type="compliant">
+if not condition1:
+  return
+# ...
+if not condition2:
+  return
+  # ...
+  for i in range(10):
+    # ...
+    if condition3:
+      if condition4:
+        if condition5:
+          # ...
+</pre>
+<h2>Resources</h2>
+<ul>
+  <li> <a href="https://en.wikipedia.org/wiki/Guard_(computer_science)">Guard clauses in programming</a> - one of the approaches to reducing the depth
+  of nesting </li>
+</ul>
 
diff --git a/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S1481.html b/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S1481.html
index 0b280f70b8..18c588541b 100644
--- a/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S1481.html
+++ b/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S1481.html
@@ -1,28 +1,49 @@
 <h2>Why is this an issue?</h2>
-<p>If a local variable is declared but not used, it is dead code and should be removed. Doing so will improve maintainability because developers will
-not wonder what the variable is used for.</p>
-<h3>Noncompliant code example</h3>
+<p>An unused local variable is a variable that has been declared but is not used anywhere in the block of code where it is defined. It is dead code,
+contributing to unnecessary complexity and leading to confusion when reading the code. Therefore, it should be removed from your code to maintain
+clarity and efficiency.</p>
+<h3>What is the potential impact?</h3>
+<p>Having unused local variables in your code can lead to several issues:</p>
+<ul>
+  <li> Decreased Readability: Unused variables can make your code more difficult to read. They add extra lines and complexity, which can distract from
+  the main logic of the code. </li>
+  <li> Misunderstanding: When other developers read your code, they may wonder why a variable is declared but not used. This can lead to confusion and
+  misinterpretation of the code’s intent. </li>
+  <li> Potential for Bugs: If a variable is declared but not used, it might indicate a bug or incomplete code. For example, if you declared a variable
+  intending to use it in a calculation, but then forgot to do so, your program might not work as expected. </li>
+  <li> Maintenance Issues: Unused variables can make code maintenance more difficult. If a programmer sees an unused variable, they might think it is
+  a mistake and try to 'fix' the code, potentially introducing new bugs. </li>
+  <li> Memory Usage: Although modern compilers are smart enough to ignore unused variables, not all compilers do this. In such cases, unused variables
+  take up memory space, leading to inefficient use of resources. </li>
+</ul>
+<p>In summary, unused local variables can make your code less readable, more confusing, and harder to maintain, and they can potentially lead to bugs
+or inefficient memory use. Therefore, it is best to remove them.</p>
+<h3>Exceptions</h3>
+<p><code>_</code> will not raise an issue for this rule. The following examples are compliant:</p>
 <pre>
+for _ in range(10):
+    do_something()
+username, login, _ = auth
+do_something_else(username, login)
+</pre>
+<h2>How to fix it</h2>
+<p>The fix for this issue is straightforward. Once you ensure the unused variable is not part of an incomplete implementation leading to bugs, you
+just need to remove it.</p>
+<h3>Code examples</h3>
+<h4>Noncompliant code example</h4>
+<pre data-diff-id="1" data-diff-type="noncompliant">
 def hello(name):
-    message = "Hello " + name # Noncompliant
+    message = "Hello " + name # Noncompliant - message is unused
     print(name)
-for i in range(10):
+for i in range(10): # Noncompliant - i is unused
     foo()
 </pre>
-<h3>Compliant solution</h3>
-<pre>
+<h4>Compliant solution</h4>
+<pre data-diff-id="1" data-diff-type="compliant">
 def hello(name):
     message = "Hello " + name
     print(message)
 for _ in range(10):
     foo()
 </pre>
-<h3>Exceptions</h3>
-<p><code>_</code> will not raise an issue for this rule. The following examples are compliant:</p>
-<pre>
-for _ in range(10):
-    do_something()
-username, login, _ = auth
-do_something_else(username, login)
-</pre>
 
diff --git a/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S1854.html b/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S1854.html
index 944342a33c..3bf9889ebf 100644
--- a/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S1854.html
+++ b/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S1854.html
@@ -1,26 +1,38 @@
 <h2>Why is this an issue?</h2>
-<p>A dead store happens when a local variable is assigned a value that is not read by any subsequent instruction. Calculating or retrieving a value
-only to then overwrite it or throw it away, could indicate a serious error in the code. Even if it’s not an error, it is at best a waste of resources.
-Therefore all calculated values should be used.</p>
-<h3>Noncompliant code example</h3>
-<pre>
+<p>Dead stores refer to assignments made to local variables that are subsequently never used or immediately overwritten. Such assignments are
+unnecessary and don’t contribute to the functionality or clarity of the code. They may even negatively impact performance. Removing them enhances code
+cleanliness and readability. Even if the unnecessary operations do not do any harm in terms of the program’s correctness, they are - at best - a waste
+of computing resources.</p>
+<h3>Exceptions</h3>
+<p>This rule ignores initializations to <code>-1</code>, <code>0</code>, <code>1</code>, <code>None</code>, <code>True</code>, <code>False</code> and
+<code>""</code>. No issue will be raised on unpacked variables.</p>
+<h2>How to fix it</h2>
+<p>Remove the unnecesarry assignment, then test the code to make sure that the right-hand side of a given assignment had no side effects (e.g. a
+method that writes certain data to a file and returns the number of written bytes).</p>
+<h3>Code examples</h3>
+<h4>Noncompliant code example</h4>
+<pre data-diff-id="1" data-diff-type="noncompliant">
 def func(a, b, compute):
     i = a + b  # Noncompliant; calculation result not used before value is overwritten
     i = compute()
     return i
 </pre>
-<h3>Compliant solution</h3>
-<pre>
+<h4>Compliant solution</h4>
+<pre data-diff-id="1" data-diff-type="compliant">
 def func(a, b, compute):
     i = a + b
     i += compute()
     return i
 </pre>
-<h3>Exceptions</h3>
-<p>This rule ignores initializations to -1, 0, 1, <code>None</code>, <code>True</code>, <code>False</code> and <code>""</code>.</p>
-<p>No issue will be raised on unpacked variables.</p>
 <h2>Resources</h2>
+<h3>Standards</h3>
+<ul>
+  <li> CWE - <a href="https://cwe.mitre.org/data/definitions/563">563 - Assignment to Variable without Use ('Unused Variable')</a> </li>
+</ul>
+<h3>Related rules</h3>
 <ul>
-  <li> <a href="https://cwe.mitre.org/data/definitions/563">MITRE, CWE-563</a> - Assignment to Variable without Use ('Unused Variable') </li>
+  <li> {rule:python:S1763} - All code should be reachable </li>
+  <li> {rule:python:S3516} - Functions returns should not be invariant </li>
+  <li> {rule:python:S3626} - Jump statements should not be redundant </li>
 </ul>
 
diff --git a/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S1854.json b/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S1854.json
index 0344bd02d2..1b1e0545e6 100644
--- a/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S1854.json
+++ b/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S1854.json
@@ -10,7 +10,7 @@
   "status": "ready",
   "remediation": {
     "func": "Constant\/Issue",
-    "constantCost": "15min"
+    "constantCost": "1min"
   },
   "tags": [
     "cwe",
diff --git a/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S1871.html b/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S1871.html
index d256b7955b..9a0f3dfc11 100644
--- a/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S1871.html
+++ b/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S1871.html
@@ -1,8 +1,8 @@
 <h2>Why is this an issue?</h2>
-<p>Having two branches in the same <code>if</code> structure with the same implementation is at best duplicate code, and at worst a coding error. If
-the same logic is truly needed for both instances, then they should be combined.</p>
-<h3>Noncompliant code example</h3>
-<pre>
+<p>When the same code is duplicated in two or more separate branches of a conditional, it can make the code harder to understand, maintain, and can
+potentially introduce bugs if one instance of the code is changed but others are not.</p>
+<p>Having two branches in the same <code>if</code> structure with the same implementation is at best duplicate code, and at worst a coding error.</p>
+<pre data-diff-id="1" data-diff-type="noncompliant">
 if 0 &lt;= a &lt; 10:
     do_first()
     do_second()
@@ -12,6 +12,14 @@ <h3>Noncompliant code example</h3>
     do_first()         # Noncompliant; duplicates first condition
     do_second()
 </pre>
+<p>If the same logic is needed for both instances, then the conditions should be combined.</p>
+<pre data-diff-id="1" data-diff-type="compliant">
+if (0 &lt;= a &lt; 10) or (20 &lt;= a &lt; 50):
+    do_first()
+    do_second()
+elif 10 &lt;= a &lt; 20:
+    do_the_other_thing()
+</pre>
 <h3>Exceptions</h3>
 <p>Blocks in an <code>if</code> chain that contain a single line of code are ignored.</p>
 <pre>
@@ -22,7 +30,7 @@ <h3>Exceptions</h3>
 elif 20 &lt;= a &lt; 50:
     do_first()         # no issue, usually this is done on purpose to increase the readability
 </pre>
-<p>But this exception does not apply to <code>if</code> chains without <code>else</code>-s when all branches have the same single line of code. In
+<p>But this exception does not apply to <code>if</code> chains without <code>else</code>-s when all branches have the same single line of code. In the
 case of <code>if</code> chains with <code>else</code>-s rule {rule:python:S3923} raises a bug.</p>
 <pre>
 if 0 &lt;= a &lt; 10:
@@ -30,4 +38,9 @@ <h3>Exceptions</h3>
 elif 20 &lt;= a &lt; 50:
     do_first()         # Noncompliant, this might have been done on purpose but probably not
 </pre>
+<h2>Resources</h2>
+<h3>Related rules</h3>
+<ul>
+  <li> {rule:python:S3923} - All branches in a conditional structure should not have exactly the same implementation </li>
+</ul>
 
diff --git a/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S2068.html b/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S2068.html
index 51a539649b..e69f430f3e 100644
--- a/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S2068.html
+++ b/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S2068.html
@@ -45,7 +45,6 @@ <h2>See</h2>
   </li>
   <li> <a href="https://cwe.mitre.org/data/definitions/798">MITRE, CWE-798</a> - Use of Hard-coded Credentials </li>
   <li> <a href="https://cwe.mitre.org/data/definitions/259">MITRE, CWE-259</a> - Use of Hard-coded Password </li>
-  <li> <a href="https://www.sans.org/top25-software-errors/#cat3">SANS Top 25</a> - Porous Defenses </li>
   <li> Derived from FindSecBugs rule <a href="https://h3xstream.github.io/find-sec-bugs/bugs.htm#HARD_CODE_PASSWORD">Hard Coded Password</a> </li>
 </ul>
 
diff --git a/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S2077.html b/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S2077.html
index 52941270ba..b062aaee4c 100644
--- a/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S2077.html
+++ b/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S2077.html
@@ -62,7 +62,6 @@ <h2>See</h2>
   <li> <a href="https://cwe.mitre.org/data/definitions/20">MITRE, CWE-20</a> - Improper Input Validation </li>
   <li> <a href="https://cwe.mitre.org/data/definitions/89">MITRE, CWE-89</a> - Improper Neutralization of Special Elements used in an SQL Command
   </li>
-  <li> <a href="https://www.sans.org/top25-software-errors/#cat1">SANS Top 25</a> - Insecure Interaction Between Components </li>
   <li> Derived from FindSecBugs rules <a href="https://h3xstream.github.io/find-sec-bugs/bugs.htm#SQL_INJECTION_JPA">Potential SQL/JPQL Injection
   (JPA)</a>, <a href="https://h3xstream.github.io/find-sec-bugs/bugs.htm#SQL_INJECTION_JDO">Potential SQL/JDOQL Injection (JDO)</a>, <a
   href="https://h3xstream.github.io/find-sec-bugs/bugs.htm#SQL_INJECTION_HIBERNATE">Potential SQL/HQL Injection (Hibernate)</a> </li>
diff --git a/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S2092.html b/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S2092.html
index bdeeb96045..55a11adf0d 100644
--- a/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S2092.html
+++ b/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S2092.html
@@ -44,6 +44,5 @@ <h2>See</h2>
   <li> <a href="https://cwe.mitre.org/data/definitions/311">MITRE, CWE-311</a> - Missing Encryption of Sensitive Data </li>
   <li> <a href="https://cwe.mitre.org/data/definitions/315">MITRE, CWE-315</a> - Cleartext Storage of Sensitive Information in a Cookie </li>
   <li> <a href="https://cwe.mitre.org/data/definitions/614">MITRE, CWE-614</a> - Sensitive Cookie in HTTPS Session Without 'Secure' Attribute </li>
-  <li> <a href="https://www.sans.org/top25-software-errors/#cat3">SANS Top 25</a> - Porous Defenses </li>
 </ul>
 
diff --git a/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S2208.html b/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S2208.html
index 17f1cd985d..62f1496946 100644
--- a/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S2208.html
+++ b/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S2208.html
@@ -5,7 +5,19 @@ <h2>Why is this an issue?</h2>
   <li> It reduces code readability as developers will have a hard time knowing where names come from. </li>
   <li> It clutters the local namespace, which makes debugging more difficult. </li>
 </ul>
-<p>Remember that imported names can change when you update your dependencies. A wildcard import which works today might be broken tomorrow.</p>
+<p>Remember that imported names can change when you update your dependencies. A wildcard import that works today might be broken tomorrow.</p>
+<h3>Exceptions</h3>
+<p>No issue will be raised in <code>__init__.py</code> files. Wildcard imports are a common way of populating these modules.</p>
+<p>No issue will be raised in modules doing only imports. Local modules are sometimes created as a proxy for third-party modules.</p>
+<pre>
+# file: mylibrary/pyplot.py
+try:
+    from guiqwt.pyplot import *  # Ok
+except Exception:
+    from matplotlib.pyplot import *  # Ok
+</pre>
+<p>Just keep in mind that wildcard imports might still create issues in these cases. It’s always better to import only what you need.</p>
+<h2>How to fix it</h2>
 <p>There are two ways to avoid a wildcard import:</p>
 <ul>
   <li> Replace it with <code>import mymodule</code> and access module members as <code>mymodule.myfunction</code>. If the module name is too long,
@@ -13,14 +25,15 @@ <h2>Why is this an issue?</h2>
   <li> List every imported name. If necessary import statements can be split on multiple lines using parentheses (preferred solution) or backslashes.
   </li>
 </ul>
-<h3>Noncompliant code example</h3>
+<h3>Code examples</h3>
+<h4>Noncompliant code example</h4>
 <pre>
 from math import *  # Noncompliant
 def exp(x):
     pass
 print(exp(0))   # "None" will be printed
 </pre>
-<h3>Compliant solution</h3>
+<h4>Compliant solution</h4>
 <pre>
 import math
 def exp(x):
@@ -34,17 +47,6 @@ <h3>Compliant solution</h3>
     pass
 print(m_exp(0))   # "1.0" will be printed
 </pre>
-<h3>Exceptions</h3>
-<p>No issue will be raised in <code>__init__.py</code> files. Wildcard imports are a common way of populating these modules.</p>
-<p>No issue will be raised in modules doing only imports. Local modules are sometimes created as a proxy for third-party modules.</p>
-<pre>
-# file: mylibrary/pyplot.py
-try:
-    from guiqwt.pyplot import *  # Ok
-except Exception:
-    from matplotlib.pyplot import *  # Ok
-</pre>
-<p>Just keep in mind that wildcard imports might still create issues in these cases. It’s always better to import only what you need.</p>
 <h2>Resources</h2>
 <ul>
   <li> <a href="https://docs.python.org/3.8/reference/simple_stmts.html#import">Python documentation - The import statement</a> </li>
diff --git a/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S2257.html b/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S2257.html
index 22ea3987c4..76668d6650 100644
--- a/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S2257.html
+++ b/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S2257.html
@@ -16,6 +16,5 @@ <h2>See</h2>
   <li> <a href="https://www.owasp.org/www-project-top-ten/2017/A3_2017-Sensitive_Data_Exposure">OWASP Top 10 2017 Category A3</a> - Sensitive Data
   Exposure </li>
   <li> <a href="https://cwe.mitre.org/data/definitions/327">MITRE, CWE-327</a> - Use of a Broken or Risky Cryptographic Algorithm </li>
-  <li> <a href="https://www.sans.org/top25-software-errors/#cat3">SANS Top 25</a> - Porous Defenses </li>
 </ul>
 
diff --git a/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S2612.html b/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S2612.html
index 5d45fb28eb..d0fcd246f1 100644
--- a/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S2612.html
+++ b/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S2612.html
@@ -46,6 +46,5 @@ <h2>See</h2>
   href="https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/02-Configuration_and_Deployment_Management_Testing/09-Test_File_Permission">OWASP File Permission</a> </li>
   <li> <a href="https://cwe.mitre.org/data/definitions/732">MITRE, CWE-732</a> - Incorrect Permission Assignment for Critical Resource </li>
   <li> <a href="https://cwe.mitre.org/data/definitions/266">MITRE, CWE-266</a> - Incorrect Privilege Assignment </li>
-  <li> <a href="https://www.sans.org/top25-software-errors/#cat3">SANS Top 25</a> - Porous Defenses </li>
 </ul>
 
diff --git a/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S3330.html b/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S3330.html
index 31c074c16c..a39eb8695d 100644
--- a/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S3330.html
+++ b/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S3330.html
@@ -44,7 +44,6 @@ <h2>See</h2>
   <li> <a href="https://owasp.org/www-project-top-ten/2017/A7_2017-Cross-Site_Scripting_(XSS)">OWASP Top 10 2017 Category A7</a> - Cross-Site
   Scripting (XSS) </li>
   <li> <a href="https://cwe.mitre.org/data/definitions/1004">MITRE, CWE-1004</a> - Sensitive Cookie Without 'HttpOnly' Flag </li>
-  <li> <a href="https://www.sans.org/top25-software-errors/#cat1">SANS Top 25</a> - Insecure Interaction Between Components </li>
   <li> Derived from FindSecBugs rule <a href="https://find-sec-bugs.github.io/bugs.htm#HTTPONLY_COOKIE">HTTPONLY_COOKIE</a> </li>
 </ul>
 
diff --git a/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S3457.html b/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S3457.html
index 6d63de2845..e453f4774a 100644
--- a/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S3457.html
+++ b/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S3457.html
@@ -1,20 +1,28 @@
 <h2>Why is this an issue?</h2>
-<p>Formatting strings, either with the <code>%</code> operator or <code>str.format</code> method, requires a valid string and arguments matching this
-string’s replacement fields.</p>
-<p>This also applies to loggers from the <code>logging</code> module. Internally they use <code>%-formatting</code>. The only difference is that they
-will log an error instead of raising an exception when provided arguments are invalid.</p>
-<p>Formatted string literals, also called "f-strings", are generally simpler to use, and any syntax mistake will fail at compile time. However it is
-easy to forget curly braces and it won’t raise any error.</p>
+<p>A format string is a string that contains placeholders, usually represented by special characters such as "%s" or "{}", depending on the technology
+in use. These placeholders are replaced by values when the string is printed or logged. Thus, it is required that a string is valid and arguments
+match replacement fields in this string.</p>
+<p>This applies to <a href="https://docs.python.org/3/tutorial/inputoutput.html#old-string-formatting">the % operator</a>, the <a
+href="https://docs.python.org/3/tutorial/inputoutput.html#the-string-format-method">str.format</a> method, and loggers from the <a
+href="https://docs.python.org/3/library/logging.html">logging</a> module. Internally, the latter use the <code>%-formatting</code>. The only
+difference is that they will log an error instead of raising an exception when the provided arguments are invalid.</p>
+<p>Formatted string literals (also called "f-strings"; available since Python 3.6) are generally simpler to use, and any syntax mistake will cause a
+failure at compile time. However, it is easy to forget curly braces, which will not lead to any detectable errors.</p>
 <p>This rule raises an issue when:</p>
 <ul>
-  <li> A string formatted with <code>%</code> will not return the expected string because some arguments are not used. </li>
-  <li> A string formatted with <code>str.format</code> will not return the expected string because some arguments are not used. </li>
-  <li> An "f-string" doesn’t contain any replacement field, which probably means that some curly braces are missing. </li>
+  <li> A string formatted with <code>%</code> will not return the expected text because some arguments are unused. </li>
+  <li> A string formatted with <code>str.format</code> will not return the expected string because some arguments are unused. </li>
+  <li> An "f-string" doesn’t contain any replacement field, which probably means some curly braces are missing. </li>
   <li> Loggers will log an error because their message is not formatted properly. </li>
 </ul>
 <p>Rule {rule:python:S2275} covers cases where formatting a string will raise an exception.</p>
-<h3>Noncompliant code example</h3>
-<pre>
+<h2>How to fix it</h2>
+<p>A <code>printf-</code>-style format string is a string that contains placeholders, which are replaced by values when the string is printed or
+logged. Mismatch in the format specifiers and the arguments provided can lead to incorrect strings being created.</p>
+<p>To avoid issues, a developer should ensure that the provided arguments match format specifiers.</p>
+<h3>Code examples</h3>
+<h4>Noncompliant code example</h4>
+<pre data-diff-id="1" data-diff-type="noncompliant">
 "Error %(message)s" % {"message": "something failed", "extra": "some dead code"}  # Noncompliant. Remove the unused argument "extra" or add a replacement field.
 
 "Error: User {} has not been able to access []".format("Alice", "MyFile")  # Noncompliant. Remove 1 unexpected argument or add a replacement field.
@@ -26,8 +34,8 @@ <h3>Noncompliant code example</h3>
 import logging
 logging.error("Error: User %s has not been able to access %s", "Alice")  # Noncompliant. Add 1 missing argument.
 </pre>
-<h3>Compliant solution</h3>
-<pre>
+<h4>Compliant solution</h4>
+<pre data-diff-id="1" data-diff-type="compliant">
 "Error %(message)s" % {"message": "something failed"}
 
 "Error: User {} has not been able to access {}".format("Alice", "MyFile")
diff --git a/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S3457.json b/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S3457.json
index a2396f08fb..6a2e82ce1d 100644
--- a/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S3457.json
+++ b/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S3457.json
@@ -10,7 +10,7 @@
   "status": "ready",
   "remediation": {
     "func": "Constant\/Issue",
-    "constantCost": "10min"
+    "constantCost": "1min"
   },
   "tags": [
     "confusing"
diff --git a/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S3752.html b/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S3752.html
index 1185a0599d..d360a5ff1c 100644
--- a/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S3752.html
+++ b/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S3752.html
@@ -72,7 +72,6 @@ <h2>See</h2>
   Broken Access Control </li>
   <li> <a href="https://cwe.mitre.org/data/definitions/352">MITRE, CWE-352</a> - Cross-Site Request Forgery (CSRF) </li>
   <li> <a href="https://owasp.org/www-community/attacks/csrf">OWASP: Cross-Site Request Forgery</a> </li>
-  <li> <a href="https://www.sans.org/top25-software-errors/#cat1">SANS Top 25</a> - Insecure Interaction Between Components </li>
   <li> <a href="https://docs.djangoproject.com/en/3.1/topics/http/decorators/#allowed-http-methods">Django</a> - Allowed HTTP Methods </li>
   <li> <a href="https://flask.palletsprojects.com/en/1.1.x/quickstart/#http-methods">Flask</a> - HTTP Methods </li>
 </ul>
diff --git a/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S3776.html b/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S3776.html
index 554d55e3fe..c3fd9a7968 100644
--- a/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S3776.html
+++ b/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S3776.html
@@ -1,14 +1,130 @@
+<p>This rule raises an issue when the code cognitive complexity of a function is above a certain threshold.</p>
 <h2>Why is this an issue?</h2>
-<p><a href="https://www.sonarsource.com/docs/CognitiveComplexity.pdf">Cognitive Complexity</a> is a measure of how hard the control flow of a function
-is to understand. Functions with high Cognitive Complexity will be difficult to maintain.</p>
+<p>Cognitive Complexity is a measure of how hard it is to understand the control flow of a unit of code. Code with high cognitive complexity is hard
+to read, understand, test, and modify.</p>
+<p>As a rule of thumb, high cognitive complexity is a sign that the code should be refactored into smaller, easier-to-manage pieces.</p>
+<h3>Which syntax in code does impact cognitive complexity score?</h3>
+<p>Here are the core concepts:</p>
+<ul>
+  <li> <strong>Cognitive complexity is incremented each time the code breaks the normal linear reading flow.</strong><br> This concerns, for example:
+  Loop structures, Conditionals, Catches, Switches, Jumps to label and mixed operators in condition. </li>
+  <li> <strong>Each nesting level adds a malus to the breaking call.</strong><br> During code reading, the deeper you go through nested layers, the
+  harder it becomes to keep the context in mind. </li>
+  <li> <strong>Method calls are free</strong><br> A well-picked method name is a summary of multiple lines of code. A reader can first explore a
+  high-level view of what the code is performing then go deeper and deeper by looking at called functions content.<br> <em>Note:</em> This does not
+  apply to recursive calls, those will increment cognitive score. </li>
+</ul>
+<p>The method of computation is fully detailed in the pdf linked in the resources.</p>
+<h3>What is the potential impact?</h3>
+<p>Developers spend more time reading and understanding code than writing it. High cognitive complexity slows down changes and increases the cost of
+maintenance.</p>
+<h2>How to fix it</h2>
+<p>Reducing cognitive complexity can be challenging.<br> Here are a few suggestions:</p>
+<ul>
+  <li> <strong>Extract complex conditions in a new function.</strong><br> Mixed operators in condition will increase complexity. Extracting the
+  condition in a new function with an appropriate name will reduce cognitive load. </li>
+  <li> <strong>Break down large functions.</strong><br> Large functions can be hard to understand and maintain. If a function is doing too many
+  things, consider breaking it down into smaller, more manageable functions. Each function should have a single responsibility. </li>
+  <li> <strong>Avoid deep nesting by returning early.</strong><br> To avoid the nesting of conditions, process exceptional cases first and return
+  early. </li>
+</ul>
+<h3>Code examples</h3>
+<p><strong>Extraction of a complex condition in a new function.</strong></p>
+<h4>Noncompliant code example</h4>
+<p>The code is using a complex condition and has a cognitive cost of 5.</p>
+<pre data-diff-id="1" data-diff-type="noncompliant">
+def process_eligible_users(users):
+    for user in users:             # +1 (for)
+        if ((user.is_active and    # +1 (if) +1 (nested) +1 (multiple conditions)
+            user.has_profile) or   # +1 (mixed operator)
+            user.age &gt; 18 ):
+            user.process()
+</pre>
+<h4>Compliant solution</h4>
+<p>Even if the cognitive complexity of the whole program did not change, it is easier for a reader to understand the code of the
+<code>process_eligible_users</code> function, which now only has a cognitive cost of 3.</p>
+<pre data-diff-id="1" data-diff-type="compliant">
+def process_eligible_users(users):
+    for user in users:             # +1 (for)
+        if is_eligible_user(user): # +1 (if) +1 (nested)
+            user.process()
+
+def is_eligible_user(user):
+    return ((user.is_active and user.has_profile) or user.age &gt; 18) # +1 (multiple conditions) +1 (mixed operators)
+</pre>
+<p><strong>Break down large functions.</strong></p>
+<h4>Noncompliant code example</h4>
+<p><em>Note:</em> The code is simplified here, to illustrate the purpose. Please imagine there is more happening in the process.<br></p>
+<p>The bellow code has a cognitive complexity score of 8.</p>
+<pre data-diff-id="3" data-diff-type="noncompliant">
+def process_user(user):
+    if user.is_active():             # +1 (if)
+        if user.has_profile():       # +1 (if) +1 (nested)
+            ... # process active user with profile
+        else:                        # +1 (else)
+            ... # process active user without profile
+    else:                            # +1 (else)
+        if user.has_profile():       # +1 (if) +1 (nested)
+            ... # process inactive user with profile
+        else:                        # +1 (else)
+            ... # process inactive user without profile
+</pre>
+<p>This function could be refactored into smaller functions: The complexity is spread over multiple functions and the breaks in flow are no more
+nested.<br> The <code>process_user</code> has now a complexity score of two.</p>
+<h4>Compliant solution</h4>
+<pre data-diff-id="3" data-diff-type="compliant">
+def process_user(user):
+    if user.is_active():             # +1 (if)
+        process_active_user(user)
+    else:                            # +1 (else)
+        process_inactive_user(user)
+
+def process_active_user(user):
+    if user.has_profile():           # +1 (if) +1 (nested)
+        ... # process active user with profile
+    else:                            # +1 (else)
+        ... # process active user without profile
+
+def process_inactive_user(user):
+    if user.has_profile():           # +1 (if) +1 (nested)
+        ... # process inactive user with profile
+    else:                            # +1 (else)
+        ... # process inactive user without profile
+</pre>
+<p><strong>Avoid deep nesting by returning early.</strong></p>
+<h4>Noncompliant code example</h4>
+<p>The below code has a cognitive complexity of 6.</p>
+<pre data-diff-id="4" data-diff-type="noncompliant">
+def calculate(data):
+    if data is not None:  # +1 (if)
+        total = 0
+        for item in data: # +1 (for) +1 (nested)
+            if item &gt; 0:  # +1 (if)  +2 (nested)
+                total += item * 2
+        return total
+</pre>
+<h4>Compliant solution</h4>
+<p>Checking for the edge case first flattens the <code>if</code> statements and reduces the cognitive complexity to 4.</p>
+<pre data-diff-id="4" data-diff-type="compliant">
+def calculate(data):
+    if data is None:      # +1 (if)
+        return None
+    total = 0
+    for item in data:     # +1 (for)
+        if item &gt; 0:      # +1 (if) +1 (nested)
+            total += item * 2
+    return total
+</pre>
+<h3>Pitfalls</h3>
+<p>As this code is complex, ensure that you have unit tests that cover the code before refactoring.</p>
 <h2>Resources</h2>
 <h3>Documentation</h3>
 <ul>
-  <li> <a href="https://www.sonarsource.com/docs/CognitiveComplexity.pdf">Cognitive Complexity</a> </li>
+  <li> Sonar - <a href="https://www.sonarsource.com/docs/CognitiveComplexity.pdf">Cognitive Complexity</a> </li>
 </ul>
 <h3>Articles &amp; blog posts</h3>
 <ul>
-  <li> <a href="https://www.sonarsource.com/blog/5-clean-code-tips-for-reducing-cognitive-complexity/">5 Clean Code Tips for Reducing Cognitive
-  Complexity</a> </li>
+  <li> Sonar Blog - <a href="https://www.sonarsource.com/blog/5-clean-code-tips-for-reducing-cognitive-complexity/">5 Clean Code Tips for Reducing
+  Cognitive Complexity</a> </li>
 </ul>
 
diff --git a/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S3776.json b/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S3776.json
index f18253c544..d00a267ddb 100644
--- a/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S3776.json
+++ b/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S3776.json
@@ -21,5 +21,5 @@
   "ruleSpecification": "RSPEC-3776",
   "sqKey": "S3776",
   "scope": "All",
-  "quickfix": "unknown"
+  "quickfix": "infeasible"
 }
diff --git a/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S4423.html b/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S4423.html
index 3ccd7bdd22..781971dd8a 100644
--- a/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S4423.html
+++ b/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S4423.html
@@ -173,6 +173,5 @@ <h3>Standards</h3>
   <li> <a href="https://owasp.org/www-project-top-ten/2017/A6_2017-Security_Misconfiguration">OWASP Top 10 2017 Category A6</a> - Security
   Misconfiguration </li>
   <li> <a href="https://cwe.mitre.org/data/definitions/327">MITRE, CWE-327</a> - Use of a Broken or Risky Cryptographic Algorithm </li>
-  <li> <a href="https://www.sans.org/top25-software-errors/#cat3">SANS Top 25</a> - Porous Defenses </li>
 </ul>
 
diff --git a/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S4502.html b/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S4502.html
index a8fd4eb076..23934d83bd 100644
--- a/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S4502.html
+++ b/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S4502.html
@@ -143,6 +143,5 @@ <h2>See</h2>
   <li> <a href="https://owasp.org/www-project-top-ten/2017/A6_2017-Security_Misconfiguration">OWASP Top 10 2017 Category A6</a> - Security
   Misconfiguration </li>
   <li> <a href="https://owasp.org/www-community/attacks/csrf">OWASP: Cross-Site Request Forgery</a> </li>
-  <li> <a href="https://www.sans.org/top25-software-errors/#cat1">SANS Top 25</a> - Insecure Interaction Between Components </li>
 </ul>
 
diff --git a/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S4721.html b/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S4721.html
index 2b05b88e69..6e054b80c3 100644
--- a/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S4721.html
+++ b/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S4721.html
@@ -80,6 +80,5 @@ <h2>See</h2>
   <li> <a href="https://owasp.org/Top10/A03_2021-Injection/">OWASP Top 10 2021 Category A3</a> - Injection </li>
   <li> <a href="https://owasp.org/www-project-top-ten/2017/A1_2017-Injection">OWASP Top 10 2017 Category A1</a> - Injection </li>
   <li> <a href="https://cwe.mitre.org/data/definitions/78">MITRE, CWE-78</a> - Improper Neutralization of Special Elements used in an OS Command </li>
-  <li> <a href="https://www.sans.org/top25-software-errors/#cat1">SANS Top 25</a> - Insecure Interaction Between Components </li>
 </ul>
 
diff --git a/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S4787.html b/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S4787.html
index 2595bb492e..16f2766229 100644
--- a/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S4787.html
+++ b/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S4787.html
@@ -99,6 +99,5 @@ <h2>See</h2>
   <li> <a href="https://cwe.mitre.org/data/definitions/325">MITRE, CWE-325</a> - Missing Required Cryptographic Step </li>
   <li> <a href="https://cwe.mitre.org/data/definitions/326">MITRE, CWE-326</a> - Inadequate Encryption Strength </li>
   <li> <a href="https://cwe.mitre.org/data/definitions/327">MITRE, CWE-327</a> - Use of a Broken or Risky Cryptographic Algorithm </li>
-  <li> <a href="https://www.sans.org/top25-software-errors/#cat3">SANS Top 25</a> - Porous Defenses </li>
 </ul>
 
diff --git a/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S4790.html b/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S4790.html
index 1f8deb830f..32dfd7d7e1 100644
--- a/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S4790.html
+++ b/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S4790.html
@@ -47,6 +47,5 @@ <h2>See</h2>
   <li> <a href="https://owasp.org/www-project-mobile-top-10/2016-risks/m5-insufficient-cryptography">OWASP Mobile Top 10 2016 Category M5</a> -
   Insufficient Cryptography </li>
   <li> <a href="https://cwe.mitre.org/data/definitions/1240">MITRE, CWE-1240</a> - Use of a Risky Cryptographic Primitive </li>
-  <li> <a href="https://www.sans.org/top25-software-errors/#cat3">SANS Top 25</a> - Porous Defenses </li>
 </ul>
 
diff --git a/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S4792.html b/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S4792.html
index a17ad97624..1c010ea03b 100644
--- a/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S4792.html
+++ b/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S4792.html
@@ -96,6 +96,5 @@ <h2>See</h2>
   Insufficient Logging &amp; Monitoring </li>
   <li> <a href="https://cwe.mitre.org/data/definitions/117">MITRE, CWE-117</a> - Improper Output Neutralization for Logs </li>
   <li> <a href="https://cwe.mitre.org/data/definitions/532">MITRE, CWE-532</a> - Information Exposure Through Log Files </li>
-  <li> <a href="https://www.sans.org/top25-software-errors/#cat3">SANS Top 25</a> - Porous Defenses </li>
 </ul>
 
diff --git a/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S4823.html b/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S4823.html
index 7e69b804df..8fd6c3d7a3 100644
--- a/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S4823.html
+++ b/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S4823.html
@@ -26,6 +26,5 @@ <h2>See</h2>
   <li> <a href="https://owasp.org/www-project-top-ten/2017/A1_2017-Injection">OWASP Top 10 2017 Category A1</a> - Injection </li>
   <li> <a href="https://cwe.mitre.org/data/definitions/88">MITRE, CWE-88</a> - Argument Injection or Modification </li>
   <li> <a href="https://cwe.mitre.org/data/definitions/214">MITRE, CWE-214</a> - Information Exposure Through Process Environment </li>
-  <li> <a href="https://www.sans.org/top25-software-errors/#cat1">SANS Top 25</a> - Insecure Interaction Between Components </li>
 </ul>
 
diff --git a/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S4830.html b/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S4830.html
index 70d059030f..47803f82d2 100644
--- a/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S4830.html
+++ b/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S4830.html
@@ -113,6 +113,67 @@ <h4>Using trusted certificates</h4>
 <h4>Working with self-signed certificates or non-standard CAs</h4>
 <p>In some cases, you might need to work with a server using a self-signed certificate, or a certificate issued by a CA not included in your trusted
 roots. Rather than disabling certificate validation in your code, you can add the necessary certificates to your trust store.</p>
+<h2>How to fix it in HTTPX</h2>
+<h3>Code examples</h3>
+<p>The following code contains examples of disabled certificate validation.</p>
+<p>The certificate validation gets disabled by setting <code>verify</code> to <code>False</code>. To enable validation set the value to
+<code>True</code> or do not set <code>verify</code> at all to use the secure default value.</p>
+<h4>Noncompliant code example</h4>
+<pre data-diff-id="31" data-diff-type="noncompliant">
+import httpx
+
+httpx.get('https://example.com', verify=False)  # Noncompliant
+</pre>
+<h4>Compliant solution</h4>
+<pre data-diff-id="31" data-diff-type="compliant">
+import httpx
+
+# By default, certificate validation is enabled
+httpx.get('https://example.com')
+</pre>
+<h3>How does this work?</h3>
+<p>Addressing the vulnerability of disabled TLS certificate validation primarily involves re-enabling the default validation.</p>
+<p>To avoid running into problems with invalid certificates, consider the following sections.</p>
+<h4>Using trusted certificates</h4>
+<p>If possible, always use a certificate issued by a well-known, trusted CA for your server. Most programming environments come with a predefined list
+of trusted root CAs, and certificates issued by these authorities are validated automatically. This is the best practice, and it requires no
+additional code or configuration.</p>
+<h4>Working with self-signed certificates or non-standard CAs</h4>
+<p>In some cases, you might need to work with a server using a self-signed certificate, or a certificate issued by a CA not included in your trusted
+roots. Rather than disabling certificate validation in your code, you can add the necessary certificates to your trust store.</p>
+<h2>How to fix it in aiohttp</h2>
+<h3>Code examples</h3>
+<p>The following code contains examples of disabled certificate validation.</p>
+<p>The certificate validation gets disabled by setting <code>verify_ssl</code> to <code>False</code>. To enable validation set the value to
+<code>True</code> or do not set <code>verify_ssl</code> at all to use the secure default value.</p>
+<h4>Noncompliant code example</h4>
+<pre data-diff-id="41" data-diff-type="noncompliant">
+import aiohttp
+
+async def example():
+  async with aiohttp.ClientSession() as session:
+    session.get("https://example.com", verify_ssl=False) # Noncompliant
+</pre>
+<h4>Compliant solution</h4>
+<pre data-diff-id="41" data-diff-type="compliant">
+import aiohttp
+
+# By default, certificate validation is enabled
+
+async def example():
+  async with aiohttp.ClientSession() as session:
+    session.get("https://example.com")
+</pre>
+<h3>How does this work?</h3>
+<p>Addressing the vulnerability of disabled TLS certificate validation primarily involves re-enabling the default validation.</p>
+<p>To avoid running into problems with invalid certificates, consider the following sections.</p>
+<h4>Using trusted certificates</h4>
+<p>If possible, always use a certificate issued by a well-known, trusted CA for your server. Most programming environments come with a predefined list
+of trusted root CAs, and certificates issued by these authorities are validated automatically. This is the best practice, and it requires no
+additional code or configuration.</p>
+<h4>Working with self-signed certificates or non-standard CAs</h4>
+<p>In some cases, you might need to work with a server using a self-signed certificate, or a certificate issued by a CA not included in your trusted
+roots. Rather than disabling certificate validation in your code, you can add the necessary certificates to your trust store.</p>
 <h2>Resources</h2>
 <h3>Standards</h3>
 <ul>
diff --git a/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S5122.html b/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S5122.html
index 423fe9a5da..c0e726beb4 100644
--- a/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S5122.html
+++ b/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S5122.html
@@ -74,6 +74,5 @@ <h2>See</h2>
   Cheat Sheet</a> - Cross Origin Resource Sharing </li>
   <li> <a href="https://cwe.mitre.org/data/definitions/346">MITRE, CWE-346</a> - Origin Validation Error </li>
   <li> <a href="https://cwe.mitre.org/data/definitions/942">MITRE, CWE-942</a> - Overly Permissive Cross-domain Whitelist </li>
-  <li> <a href="https://www.sans.org/top25-software-errors/#cat3">SANS Top 25</a> - Porous Defenses </li>
 </ul>
 
diff --git a/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S5300.html b/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S5300.html
index cd33cdff40..3f34f9aee2 100644
--- a/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S5300.html
+++ b/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S5300.html
@@ -67,6 +67,5 @@ <h2>See</h2>
   <li> <a href="https://cwe.mitre.org/data/definitions/93">MITRE, CWE-93</a> - Improper Neutralization of CRLF Sequences ('CRLF Injection') </li>
   <li> <a href="https://cwe.mitre.org/data/definitions/80">MITRE, CWE-80</a> - Improper Neutralization of Script-Related HTML Tags in a Web Page
   (Basic XSS) </li>
-  <li> <a href="https://www.sans.org/top25-software-errors/#cat1">SANS Top 25</a> - Insecure Interaction Between Components </li>
 </ul>
 
diff --git a/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S5439.html b/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S5439.html
index 619d162a42..f5aeb2f672 100644
--- a/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S5439.html
+++ b/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S5439.html
@@ -52,6 +52,5 @@ <h2>Resources</h2>
   <li> <a href="https://cwe.mitre.org/data/definitions/86">MITRE, CWE-86</a> - Improper Neutralization of Invalid Characters in Identifiers in Web
   Pages </li>
   <li> <a href="https://cwe.mitre.org/data/definitions/87">MITRE, CWE-87</a> - Improper Neutralization of Alternate XSS Syntax </li>
-  <li> <a href="https://www.sans.org/top25-software-errors/#cat1">SANS Top 25</a> - Insecure Interaction Between Components </li>
 </ul>
 
diff --git a/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S5542.html b/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S5542.html
index 890db491c2..8f85bf00d0 100644
--- a/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S5542.html
+++ b/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S5542.html
@@ -271,6 +271,5 @@ <h3>Standards</h3>
   <li> <a href="https://owasp.org/www-project-top-ten/2017/A6_2017-Security_Misconfiguration">OWASP Top 10 2017 Category A6</a> - Security
   Misconfiguration </li>
   <li> <a href="https://cwe.mitre.org/data/definitions/327">MITRE, CWE-327</a> - Use of a Broken or Risky Cryptographic Algorithm </li>
-  <li> <a href="https://www.sans.org/top25-software-errors/#cat3">SANS Top 25</a> - Porous Defenses </li>
 </ul>
 
diff --git a/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S5547.html b/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S5547.html
index 6324c1eeb5..201bf6b8c6 100644
--- a/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S5547.html
+++ b/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S5547.html
@@ -118,6 +118,5 @@ <h3>Standards</h3>
   <li> <a href="https://www.owasp.org/www-project-top-ten/2017/A3_2017-Sensitive_Data_Exposure">OWASP Top 10 2017 Category A3</a> - Sensitive Data
   Exposure </li>
   <li> <a href="https://cwe.mitre.org/data/definitions/327">MITRE, CWE-327</a> - Use of a Broken or Risky Cryptographic Algorithm </li>
-  <li> <a href="https://www.sans.org/top25-software-errors/#cat3">SANS Top 25</a> - Porous Defenses </li>
 </ul>
 
diff --git a/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S6353.html b/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S6353.html
index 70bdce9180..cb5d24a2e8 100644
--- a/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S6353.html
+++ b/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S6353.html
@@ -1,7 +1,14 @@
 <h2>Why is this an issue?</h2>
-<p>With regular expressions syntax, it’s possible to express the same thing in many ways. For example, to match a two-digit number, one could write
-<code>[0-9]{2,2}</code> or <code>\d{2}</code>. Latter is not only shorter in terms of expression length, but also easier to read and thus to maintain.
-This rule recommends to replace some bulky quantifiers and character classes with more concise equivalents:</p>
+<p>A regular expression is a sequence of characters that specifies a match pattern in text. Among the most important concepts are:</p>
+<ul>
+  <li> Character classes: defines a set of characters, any one of which can occur in an input string for a match to succeed. </li>
+  <li> Quantifiers: used to specify how many instances of a character, group, or character class must be present in the input for a match. </li>
+  <li> Wildcard (<code>.</code>): matches all characters except line terminators (also matches them if the <code>s</code> flag is set). </li>
+</ul>
+<p>Many of these features include shortcuts of widely used expressions, so there is more than one way to construct a regular expression to achieve the
+same results. For example, to match a two-digit number, one could write <code>[0-9]{2,2}</code> or <code>\d{2}</code>. The latter is not only shorter
+but easier to read and thus to maintain.</p>
+<p>This rule recommends replacing some quantifiers and character classes with more concise equivalents:</p>
 <ul>
   <li> <code>\d</code> for <code>[0-9]</code> and <code>\D</code> for <code>[^0-9]</code> </li>
   <li> <code>\w</code> for <code>[A-Za-z0-9_]</code> and <code>\W</code> for <code>[^A-Za-z0-9_]</code> </li>
@@ -10,16 +17,15 @@ <h2>Why is this an issue?</h2>
   <li> <code>x?</code> for <code>x{0,1}</code>, <code>x*</code> for <code>x{0,}</code>, <code>x+</code> for <code>x{1,}</code>, <code>x{N}</code> for
   <code>x{N,N}</code> </li>
 </ul>
-<h3>Noncompliant code example</h3>
-<pre>
-r"[0-9]" # Noncompliant - same as r"\d"
-r"[^0-9]" # Noncompliant - same as r"\D"
+<pre data-diff-id="1" data-diff-type="noncompliant">
+r"[0-9]"        # Noncompliant - same as r"\d"
+r"[^0-9]"       # Noncompliant - same as r"\D"
 r"[A-Za-z0-9_]" # Noncompliant - same as r"\w"
-r"[\w\W]" # Noncompliant - same as r"."
-r"a{0,}" # Noncompliant - same as r"a*"
+r"[\w\W]"       # Noncompliant - same as r"."
+r"a{0,}"        # Noncompliant - same as r"a*"
 </pre>
-<h3>Compliant solution</h3>
-<pre>
+<p>Use the more concise version to make the regex expression more readable.</p>
+<pre data-diff-id="1" data-diff-type="compliant">
 r"\d"
 r"\D"
 r"\w"
diff --git a/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S6554.html b/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S6554.html
index 565495b768..584bc1a503 100644
--- a/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S6554.html
+++ b/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S6554.html
@@ -1,11 +1,11 @@
-<p>This rule ensures that Django models have a <code><em>str</em></code> method defined.</p>
+<p>This rule ensures that Django models have a <code>__str__</code> method defined.</p>
 <h2>Why is this an issue?</h2>
-<p>The <code><em>str</em></code> method in Django models is used to represent the model instance as a string. For example, the return value of this
-method will be inserted in a template when displaying an object in the Django admin site. Without this method, the model instance will be represented
-by its object identifier, which is not meaningful to end-users. This can result in confusion and make debugging more difficult.</p>
+<p>The <code>__str__</code> method in Django models is used to represent the model instance as a string. For example, the return value of this method
+will be inserted in a template when displaying an object in the Django admin site. Without this method, the model instance will be represented by its
+object identifier, which is not meaningful to end-users. This can result in confusion and make debugging more difficult.</p>
 <h2>How to fix it</h2>
-<p>To fix this issue, the Django model must define a <code><em>str</em></code> method that returns a string representation of the instance. This
-string should be meaningful to end-users and provide information about the model instance.</p>
+<p>To fix this issue, the Django model must define a <code>__str__</code> method that returns a string representation of the instance. This string
+should be meaningful to end-users and provide information about the model instance.</p>
 <h3>Code examples</h3>
 <h4>Noncompliant code example</h4>
 <pre>
diff --git a/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S6559.html b/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S6559.html
index e10654984b..86936ea35a 100644
--- a/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S6559.html
+++ b/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S6559.html
@@ -1,10 +1,10 @@
-<p>This rule discourages the use of <code>exclude</code> or <code><em>all</em></code> with ModelForm in Django and suggests using fields instead.</p>
+<p>This rule discourages the use of <code>exclude</code> or <code>__all__</code> with ModelForm in Django and suggests using fields instead.</p>
 <h2>Why is this an issue?</h2>
 <p>In Django, when creating a <code>ModelForm</code>, it is common to use <code>exclude</code> to remove fields from the form. It is also possible to
-set the <code>fields</code> value to <code><em>all</em></code> to conveniently indicate that all the model fields should be included in the form.
-However, this can lead to security issues when new fields are added to the model, as they will automatically be included in the form, which may not be
-intended. Additionally, <code>exclude</code> or <code><em>all</em></code> can make it harder to maintain the codebase by hiding the dependencies
-between the model and the form.</p>
+set the <code>fields</code> value to <code>__all__</code> to conveniently indicate that all the model fields should be included in the form. However,
+this can lead to security issues when new fields are added to the model, as they will automatically be included in the form, which may not be
+intended. Additionally, <code>exclude</code> or <code>__all__</code> can make it harder to maintain the codebase by hiding the dependencies between
+the model and the form.</p>
 <h2>How to fix it</h2>
 <p>Developers should use the "fields" attribute instead of "exclude" or "all" when creating ModelForms in Django. This ensures that all fields are
 explicitly listed and makes it clear what fields are included in the form.</p>
diff --git a/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S6660.html b/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S6660.html
index 3d16341f87..51e5161584 100644
--- a/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S6660.html
+++ b/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S6660.html
@@ -31,7 +31,7 @@ <h4>Noncompliant code example</h4>
 class MyClass:
   ...
 
-def foo(a)
+def foo(a):
   if type(a) == MyClass: # Noncompliant
     ...
 </pre>
@@ -40,7 +40,7 @@ <h4>Compliant solution</h4>
 class MyClass:
   ...
 
-def foo(a)
+def foo(a):
   if isinstance(a, MyClass):
     ...
 </pre>
diff --git a/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S6660.json b/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S6660.json
index 3087ef3485..bc685467e3 100644
--- a/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S6660.json
+++ b/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S6660.json
@@ -1,6 +1,12 @@
 {
-  "title": "\u0027isinstance()\u0027 should be preferred to direct type comparisons",
+  "title": "\"isinstance()\" should be preferred to direct type comparisons",
   "type": "CODE_SMELL",
+  "code": {
+    "impacts": {
+      "MAINTAINABILITY": "MEDIUM"
+    },
+    "attribute": "CONVENTIONAL"
+  },
   "status": "ready",
   "remediation": {
     "func": "Constant\/Issue",
diff --git a/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S6799.html b/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S6799.html
index b71f54c7c2..ed5048cfd1 100644
--- a/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S6799.html
+++ b/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S6799.html
@@ -1,25 +1,25 @@
-<p>This rule raises an issue f-strings are deeply nested.</p>
+<p>This rule raises an issue when "f-strings" are deeply nested.</p>
 <h2>Why is this an issue?</h2>
-<p>Through <a href="https://peps.python.org/pep-0701/">PEP 701</a>, Python 3.12 lifts restrictions on how to construct f-strings.</p>
-<p>Prior to Python 3.12, it was not possible to reuse string quotes when nesting f-strings. Therefore, the maximum level of nesting was:</p>
+<p>Through <a href="https://peps.python.org/pep-0701/">PEP 701</a>, Python 3.12 lifts restrictions on how to construct "f-strings".</p>
+<p>Prior to Python 3.12, it was not possible to reuse string quotes when nesting "f-strings". Therefore, the maximum level of nesting was:</p>
 <pre>
 f"""{f'''{f'{f"{1+1}"}'}'''}"""
 </pre>
-<p>It is now possible to arbitrarily nest f-strings by reusing string quotes. The following snippet is therefore valid:</p>
+<p>It is now possible to arbitrarily nest "f-strings" by reusing string quotes. The following snippet is therefore valid:</p>
 <pre>
 f"{f"{f"{f"{f"{f"{1+1}"}"}"}"}"}"
 </pre>
-<p>It is, however, not recommended to nest f-strings too deeply as this would make the code confusing and hard to maintain.</p>
-<p>This rule will raise an issue if f-strings literals are nested more than 3 times.</p>
+<p>It is, however, not recommended to nest "f-strings" too deeply as this would make the code confusing and hard to maintain.</p>
+<p>This rule will raise an issue when "f-string" literals are nested 3 times or more.</p>
 <h2>How to fix it</h2>
-<p>To fix this issue, refactor the code to avoid nesting f-string literals too deeply. This may be done by introducing new variables to store
+<p>To fix this issue, refactor the code to avoid nesting "f-string" literals too deeply. This may be done by introducing new variables to store
 intermediate results.</p>
 <h3>Code examples</h3>
 <h4>Noncompliant code example</h4>
 <pre data-diff-id="1" data-diff-type="noncompliant">
 hello = "Hello"
 name = "John"
-my_string = f"{f"{f"{hello}"},"} {name}!" # Noncompliant: deep nesting of f-strings is confusing
+my_string = f"{f"{f"{hello}"},"} {name}!" # Noncompliant: deep nesting of "f-strings" is confusing
 </pre>
 <h4>Compliant solution</h4>
 <pre data-diff-id="1" data-diff-type="compliant">
@@ -31,7 +31,7 @@ <h4>Compliant solution</h4>
 <h2>Resources</h2>
 <h3>Documentation</h3>
 <ul>
-  <li> PEP 701 <a href="https://peps.python.org/pep-0701/">Syntactic formalization of f-strings</a> </li>
-  <li> Python Release Notes <a href="https://docs.python.org/3/whatsnew/3.12.html#what-s-new-in-python-3-12">What’s New In Python 3.12</a> </li>
+  <li> PEP 701 - <a href="https://peps.python.org/pep-0701/">Syntactic formalization of "f-strings"</a> </li>
+  <li> Python Release Notes - <a href="https://docs.python.org/3/whatsnew/3.12.html#what-s-new-in-python-3-12">What’s New In Python 3.12</a> </li>
 </ul>
 
diff --git a/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S6799.json b/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S6799.json
index 33948088c5..408bfedfc4 100644
--- a/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S6799.json
+++ b/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S6799.json
@@ -1,5 +1,5 @@
 {
-  "title": "f-strings should not be nested too deeply",
+  "title": "\"f-strings\" should not be nested too deeply",
   "type": "CODE_SMELL",
   "status": "ready",
   "remediation": {
diff --git a/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S905.html b/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S905.html
index 8d1aadfdef..fc50ebf254 100644
--- a/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S905.html
+++ b/python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S905.html
@@ -1,23 +1,29 @@
+<p>Statements with no side effects and no change of control flow do not contribute to the functionality of the code and can indicate a programming
+error.</p>
 <h2>Why is this an issue?</h2>
-<p>Any statement, other than a <code>pass</code>, <code>...</code> (ellipsis) or an empty statement (i.e. a single semicolon "<code>;</code>"), which
-has no side effect and does not result in a change of control flow will normally indicate a programming error, and therefore should be refactored.</p>
-<h3>Noncompliant code example</h3>
-<pre>
-a == 1 # Noncompliant; was assignment intended?
-a &lt; b # Noncompliant; have we forgotten to assign the result to a variable?
-</pre>
+<p>When writing code, it is important to ensure that each statement serves a purpose and contributes to the overall functionality of the program. When
+they have no side effects or do not change the control flow, they can either indicate a programming error or be redundant:</p>
+<ol>
+  <li> The code does not behave as intended: The statements are expected to have an effect but they do not. This can be caused by mistyping,
+  copy-and-paste errors, etc. </li>
+  <li> The statements are residual after a refactoring. </li>
+</ol>
 <h3>Exceptions</h3>
+<p><strong>Intentionally empty statement</strong></p>
+<p>Statements such as <code>pass</code> or <code>...</code> (ellipsis) are clearly meant to have no effect and may be used to indicate an
+implementation is missing. No issue will be raised in this case.</p>
 <p><strong>Strings</strong></p>
 <p>Some projects use string literals as comments. By default, this rule will not raise an issue on these strings. Reporting on string literals can be
-enabled by setting the rule parameter "reportOnStrings" to "true".</p>
+enabled by setting the rule parameter <code>reportOnStrings</code> to <code>true</code>.</p>
 <pre>
-class MyClass:
-    myattr = 42
-    """This is an attribute"""  # Noncompliant by default. Set "reportOnStrings" to "false"
+def foo():
+    bar()
+    """Some comment"""  # Compliant by default. Noncompliant with "reportOnStrings" set to "true"
+    qix()
 </pre>
 <p><strong>Operators</strong></p>
-<p>By default, this rule considers that no arithmetic operator has a side effect. Some rare projects redefine operators and add a side effect. You can
-list such operators in the rule parameter "ignoredOperators".</p>
+<p>By default, this rule considers that no arithmetic operator has a side effect. Some projects may redefine operators and add a side effect. You can
+list such operators in the rule parameter <code>ignoredOperators</code>.</p>
 <pre>
 def process(p, beam):
     """
@@ -26,8 +32,29 @@ <h3>Exceptions</h3>
     """
     p | "create" &gt;&gt; beam.Create()  # Noncompliant by default
 </pre>
+<h2>How to fix it</h2>
+<p>Identify statements that do not contribute to the functionality of the code and verify if they are intended to be part of the logic. If they are,
+there is a bug to be fixed. If they are not, then they are redundant and should be removed.</p>
+<h3>Code examples</h3>
+<h4>Noncompliant code example</h4>
+<pre>
+def get_result():
+    result = 42
+    if should_be_zero():
+        result == 0 # Noncompliant: no side effect, was an assignment intended?
+    return result
+</pre>
+<h4>Compliant solution</h4>
+<pre>
+def get_result():
+    result = 42
+    if should_be_zero():
+        result = 0 # Compliant
+    return result
+</pre>
 <h2>Resources</h2>
+<h3>Standards</h3>
 <ul>
-  <li> <a href="https://cwe.mitre.org/data/definitions/482">MITRE, CWE-482</a> - Comparing instead of Assigning </li>
+  <li> CWE - <a href="https://cwe.mitre.org/data/definitions/482">482 Comparing instead of Assigning</a> </li>
 </ul>
 
diff --git a/sonarpedia.json b/sonarpedia.json
index 8f5e5b926d..f4a3a97a7e 100644
--- a/sonarpedia.json
+++ b/sonarpedia.json
@@ -3,7 +3,7 @@
   "languages": [
     "PY"
   ],
-  "latest-update": "2023-10-09T13:33:42.838821515Z",
+  "latest-update": "2023-11-01T11:03:52.033339700Z",
   "options": {
     "no-language-in-filenames": true,
     "preserve-filenames": true