SONARKT-413 Update rules metadata

Author: Godin

sonar-kotlin-plugin/sonarpedia.json

@@ -3,7 +3,7 @@
   "languages": [
     "KOTLIN"
   ],
-  "latest-update": "2023-12-14T11:00:42.692746Z",
+  "latest-update": "2024-11-25T09:36:33.523743Z",
   "options": {
     "no-language-in-filenames": true,
     "preserve-filenames": true

sonar-kotlin-plugin/src/main/resources/org/sonar/l10n/kotlin/rules/kotlin/ParsingError.json

@@ -13,5 +13,5 @@
   "ruleSpecification": "RSPEC-2260",
   "sqKey": "S2260",
   "scope": "All",
-  "quickfix": "unknown"
+  "quickfix": "infeasible"
 }

sonar-kotlin-plugin/src/main/resources/org/sonar/l10n/kotlin/rules/kotlin/S107.html

@@ -1,5 +1,5 @@
 <h2>Why is this an issue?</h2>
-<p>Functions with a long parameter list are difficult to use, as maintainers must figure out the role of each parameter and keep track of their
+<p>Functions with a long parameter list are difficult to use because maintainers must figure out the role of each parameter and keep track of their
 position.</p>
 <pre>
 fun setCoordinates(x1: Int, y1: Int, z1: Int, x2: Int, y2: Int, z2: Int) { // Noncompliant

sonar-kotlin-plugin/src/main/resources/org/sonar/l10n/kotlin/rules/kotlin/S1125.html

@@ -4,7 +4,7 @@ <h2>Why is this an issue?</h2>
 variable or expression that evaluates to a boolean value is unnecessary and can make the code harder to read and understand. The more complex a
 boolean expression is, the harder it will be for developers to understand its meaning and expected behavior, and it will favour the introduction of
 new bugs.</p>
-<h2>How to tix it</h2>
+<h2>How to fix it</h2>
 <p>Remove redundant boolean literals from expressions to improve readability and make the code more maintainable.</p>
 <h3>Code examples</h3>
 <h4>Noncompliant code example</h4>

sonar-kotlin-plugin/src/main/resources/org/sonar/l10n/kotlin/rules/kotlin/S1133.json

@@ -19,5 +19,5 @@
   "ruleSpecification": "RSPEC-1133",
   "sqKey": "S1133",
   "scope": "All",
-  "quickfix": "unknown"
+  "quickfix": "infeasible"
 }

sonar-kotlin-plugin/src/main/resources/org/sonar/l10n/kotlin/rules/kotlin/S1134.html

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

sonar-kotlin-plugin/src/main/resources/org/sonar/l10n/kotlin/rules/kotlin/S1135.html

@@ -1,8 +1,8 @@
 <h2>Why is this an issue?</h2>
 <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>
+immediately. However, these <code>TODO</code> tags sometimes get overlooked or forgotten, leading to incomplete or unfinished code. This rule aims to
+identify and address unattended <code>TODO</code> tags to ensure a clean and maintainable codebase. This description explores why this is a problem
+and how it can be fixed to improve the overall code quality.</p>
 <h3>What is the potential impact?</h3>
 <p>Unattended <code>TODO</code> tags in code can have significant implications for the development process and the overall codebase.</p>
 <p>Incomplete Functionality: When developers leave <code>TODO</code> tags without implementing the corresponding code, it results in incomplete
@@ -11,8 +11,8 @@ <h3>What is the potential impact?</h3>
 Delayed bug fixes can result in more severe issues and increase the effort required to resolve them later.</p>
 <p>Impact on Collaboration: In team-based development environments, unattended <code>TODO</code> tags can hinder collaboration. Other team members
 might not be aware of the intended changes, leading to conflicts or redundant efforts in the codebase.</p>
-<p>Codebase Bloat: Accumulation of unattended <code>TODO</code> tags over time can clutter the codebase and make it difficult to distinguish between
-work in progress and completed code. This bloat can make it challenging to maintain an organized and efficient codebase.</p>
+<p>Codebase Bloat: The accumulation of unattended <code>TODO</code> tags over time can clutter the codebase and make it difficult to distinguish
+between work in progress and completed code. This bloat can make it challenging to maintain an organized and efficient codebase.</p>
 <p>Addressing this code smell is essential to ensure a maintainable, readable, reliable codebase and promote effective collaboration among
 developers.</p>
 <h3>Noncompliant code example</h3>
@@ -23,6 +23,6 @@ <h3>Noncompliant code example</h3>
 </pre>
 <h2>Resources</h2>
 <ul>
-  <li> <a href="https://cwe.mitre.org/data/definitions/546">MITRE, CWE-546</a> - Suspicious Comment </li>
+  <li> CWE - <a href="https://cwe.mitre.org/data/definitions/546">CWE-546 - Suspicious Comment</a> </li>
 </ul>
 

sonar-kotlin-plugin/src/main/resources/org/sonar/l10n/kotlin/rules/kotlin/S1135.json

@@ -24,5 +24,5 @@
       546
     ]
   },
-  "quickfix": "unknown"
+  "quickfix": "infeasible"
 }

sonar-kotlin-plugin/src/main/resources/org/sonar/l10n/kotlin/rules/kotlin/S1145.html

@@ -25,8 +25,8 @@ <h3>Compliant solution</h3>
 </pre>
 <h2>Resources</h2>
 <ul>
-  <li> <a href="https://cwe.mitre.org/data/definitions/489">MITRE, CWE-489</a> - Active Debug Code </li>
-  <li> <a href="https://cwe.mitre.org/data/definitions/570">MITRE, CWE-570</a> - Expression is Always False </li>
-  <li> <a href="https://cwe.mitre.org/data/definitions/571">MITRE, CWE-571</a> - Expression is Always True </li>
+  <li> CWE - <a href="https://cwe.mitre.org/data/definitions/489">CWE-489 - Active Debug Code</a> </li>
+  <li> CWE - <a href="https://cwe.mitre.org/data/definitions/570">CWE-570 - Expression is Always False</a> </li>
+  <li> CWE - <a href="https://cwe.mitre.org/data/definitions/571">CWE-571 - Expression is Always True</a> </li>
 </ul>
 

sonar-kotlin-plugin/src/main/resources/org/sonar/l10n/kotlin/rules/kotlin/S117.html

@@ -9,15 +9,17 @@ <h2>Why is this an issue?</h2>
 <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>
+  <li> <strong>Reduced Readability</strong>: 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> <strong>Difficulty in Identifying Variables</strong>: The 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> <strong>Increased Risk of Errors</strong>: 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> <strong>Collaboration Difficulties</strong>: In a team setting, inconsistent naming conventions lead to confusion and miscommunication among
+  team members. </li>
+  <li> <strong>Difficulty in Code Maintenance</strong>: 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>