SONARSCALA-119 Update rule metadata (#111)

hashicorp-vault-sonar-prod[bot] · tomasz-tylenda-sonarsource · web-flow · commit e4e67bf861e5 · 2026-03-05T14:37:04.000+01:00
Co-authored-by: tomasz-tylenda-sonarsource &lt;tomasz-tylenda-sonarsource@users.noreply.github.com&gt;
diff --git a/sonar-scala-plugin/sonarpedia.json b/sonar-scala-plugin/sonarpedia.json
@@ -3,7 +3,7 @@
   "languages": [
     "SCALA"
   ],
-  "latest-update": "2026-01-08T15:29:44.574249187Z",
+  "latest-update": "2026-03-02T10:56:52.285760582Z",
   "options": {
     "no-language-in-filenames": true,
     "preserve-filenames": true
diff --git a/sonar-scala-plugin/src/main/resources/org/sonar/l10n/scala/rules/scala/S107.html b/sonar-scala-plugin/src/main/resources/org/sonar/l10n/scala/rules/scala/S107.html
@@ -8,7 +8,7 @@ <h2>Why is this an issue?</h2>
 </pre>
 <p>The solution can be to:</p>
 <ul>
-  <li> Split the function into smaller ones </li>
+  <li>Split the function into smaller ones</li>
 </ul>
 <pre>
 // Each function does a part of what the original setCoordinates function was doing, so confusion risks are lower
@@ -21,7 +21,7 @@ <h2>Why is this an issue?</h2>
 }
 </pre>
 <ul>
-  <li> Find a better data structure for the parameters that group data in a way that makes sense for the specific application domain </li>
+  <li>Find a better data structure for the parameters that group data in a way that makes sense for the specific application domain</li>
 </ul>
 <pre>
 class Point(var x: Int, var y: Int, var z: Int) { // In geometry, Point is a logical structure to group data
diff --git a/sonar-scala-plugin/src/main/resources/org/sonar/l10n/scala/rules/scala/S1134.html b/sonar-scala-plugin/src/main/resources/org/sonar/l10n/scala/rules/scala/S1134.html
@@ -8,6 +8,6 @@ <h2>Why is this an issue?</h2>
 <h2>Resources</h2>
 <h3>Documentation</h3>
 <ul>
-  <li> CWE - <a href="https://cwe.mitre.org/data/definitions/546">CWE-546 - Suspicious Comment</a> </li>
+  <li>CWE - <a href="https://cwe.mitre.org/data/definitions/546">CWE-546 - Suspicious Comment</a></li>
 </ul>
 
diff --git a/sonar-scala-plugin/src/main/resources/org/sonar/l10n/scala/rules/scala/S1135.html b/sonar-scala-plugin/src/main/resources/org/sonar/l10n/scala/rules/scala/S1135.html
@@ -17,6 +17,6 @@ <h3>What is the potential impact?</h3>
 developers.</p>
 <h2>Resources</h2>
 <ul>
-  <li> CWE - <a href="https://cwe.mitre.org/data/definitions/546">CWE-546 - Suspicious Comment</a> </li>
+  <li>CWE - <a href="https://cwe.mitre.org/data/definitions/546">CWE-546 - Suspicious Comment</a></li>
 </ul>
 
diff --git a/sonar-scala-plugin/src/main/resources/org/sonar/l10n/scala/rules/scala/S1144.html b/sonar-scala-plugin/src/main/resources/org/sonar/l10n/scala/rules/scala/S1144.html
@@ -22,12 +22,12 @@ <h3>Compliant solution</h3>
 <h3>Exceptions</h3>
 <p>This rule doesn’t raise issues for:</p>
 <ul>
-  <li> annotated methods </li>
-  <li> methods with parameters that are annotated with one of the following: </li>
-  <li> <code>@javax.enterprise.event.Observes</code> </li>
-  <li> <code>@javax.enterprise.event.ObservesAsync</code> </li>
-  <li> <code>@jakarta.enterprise.event.Observes</code> </li>
-  <li> <code>@jakarta.enterprise.event.ObservesAsync</code> </li>
+  <li>annotated methods</li>
+  <li>methods with parameters that are annotated with one of the following:</li>
+  <li><code>@javax.enterprise.event.Observes</code></li>
+  <li><code>@javax.enterprise.event.ObservesAsync</code></li>
+  <li><code>@jakarta.enterprise.event.Observes</code></li>
+  <li><code>@jakarta.enterprise.event.ObservesAsync</code></li>
 </ul>
 <p>The rule does not take reflection into account, which means that issues will be raised on <code>private</code> methods that are only accessed using
 the reflection API.</p>
diff --git a/sonar-scala-plugin/src/main/resources/org/sonar/l10n/scala/rules/scala/S1145.html b/sonar-scala-plugin/src/main/resources/org/sonar/l10n/scala/rules/scala/S1145.html
@@ -3,9 +3,9 @@ <h2>Why is this an issue?</h2>
 statements with conditions that are always true are completely redundant, and make the code less readable.</p>
 <p>There are three possible causes for the presence of such code:</p>
 <ul>
-  <li> An if statement was changed during debugging and that debug code has been committed. </li>
-  <li> Some value was left unset. </li>
-  <li> Some logic is not doing what the programmer thought it did. </li>
+  <li>An if statement was changed during debugging and that debug code has been committed.</li>
+  <li>Some value was left unset.</li>
+  <li>Some logic is not doing what the programmer thought it did.</li>
 </ul>
 <p>In any of these cases, unconditional <code>if</code> statements should be removed.</p>
 <h3>Noncompliant code example</h3>
@@ -25,8 +25,8 @@ <h3>Compliant solution</h3>
 </pre>
 <h2>Resources</h2>
 <ul>
-  <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>
+  <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>
 
diff --git a/sonar-scala-plugin/src/main/resources/org/sonar/l10n/scala/rules/scala/S117.html b/sonar-scala-plugin/src/main/resources/org/sonar/l10n/scala/rules/scala/S117.html
@@ -1,25 +1,27 @@
 <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>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>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> <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>
+  <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>
@@ -45,12 +47,12 @@ <h4>Compliant solution</h4>
 <h2>Resources</h2>
 <h3>Documentation</h3>
 <ul>
-  <li> Scala documentation - <a href="https://docs.scala-lang.org/style/naming-conventions.html">Style guide: naming conventions</a> </li>
-  <li> Wikipedia - <a href="https://en.wikipedia.org/wiki/Naming_convention_(programming)">Naming Convention (programming)</a> </li>
+  <li>Scala documentation - <a href="https://docs.scala-lang.org/style/naming-conventions.html">Style guide: 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:scala:S100} - Function names should comply with a naming convention </li>
-  <li> {rule:scala:S101} - Class names should comply with a naming convention </li>
+  <li>{rule:scala:S100} - Function names should comply with a naming convention</li>
+  <li>{rule:scala:S101} - Class names should comply with a naming convention</li>
 </ul>
 
diff --git a/sonar-scala-plugin/src/main/resources/org/sonar/l10n/scala/rules/scala/S1186.html b/sonar-scala-plugin/src/main/resources/org/sonar/l10n/scala/rules/scala/S1186.html
@@ -3,9 +3,9 @@ <h2>Why is this an issue?</h2>
 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>
+  <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>
 <h2>How to fix it</h2>
 <h3>Code examples</h3>
diff --git a/sonar-scala-plugin/src/main/resources/org/sonar/l10n/scala/rules/scala/S126.html b/sonar-scala-plugin/src/main/resources/org/sonar/l10n/scala/rules/scala/S126.html
@@ -4,6 +4,10 @@ <h2>Why is this an issue?</h2>
 <p>The requirement for a final <code>else</code> statement is defensive programming.</p>
 <p>The <code>else</code> statement should either take appropriate action or contain a suitable comment as to why no action is taken. This is
 consistent with the requirement to have a final <code>case _</code> clause in a <code>match</code>.</p>
+<p>In Scala, this rule also applies when an <code>if</code> statement without an <code>else</code> clause appears on the right-hand side of an
+assignment. Since Scala treats <code>if</code> as an expression that returns a value, omitting the <code>else</code> clause results in the assignment
+receiving <code>Unit</code> (represented as <code>()</code>) when the condition is false, which is typically unintended and can lead to type errors or
+unexpected behavior.</p>
 <h3>Noncompliant code example</h3>
 <pre>
 if (x == 0) {
@@ -12,6 +16,11 @@ <h3>Noncompliant code example</h3>
   doSomethingElse
 }
 </pre>
+<pre>
+val result = if (x == 0) {
+  "zero"
+}
+</pre>
 <h3>Compliant solution</h3>
 <pre>
 if (x == 0) {
@@ -22,6 +31,13 @@ <h3>Compliant solution</h3>
   throw new IllegalStateException
 }
 </pre>
+<pre>
+val result = if (x == 0) {
+  "zero"
+} else {
+  "not zero"
+}
+</pre>
 <h3>Exceptions</h3>
 <p>When all branches of an <code>if</code>-<code>else if</code> end with <code>return</code>, <code>break</code> or <code>throw</code>, the code that
 comes after the <code>if</code> implicitly behaves as if it was in an <code>else</code> clause. This rule will therefore ignore that case.</p>
diff --git a/sonar-scala-plugin/src/main/resources/org/sonar/l10n/scala/rules/scala/S1313.html b/sonar-scala-plugin/src/main/resources/org/sonar/l10n/scala/rules/scala/S1313.html
@@ -1,14 +1,14 @@
 <p>Hardcoding IP addresses is security-sensitive. It has led in the past to the following vulnerabilities:</p>
 <ul>
-  <li> <a href="https://www.cve.org/CVERecord?id=CVE-2006-5901">CVE-2006-5901</a> </li>
-  <li> <a href="https://www.cve.org/CVERecord?id=CVE-2005-3725">CVE-2005-3725</a> </li>
+  <li><a href="https://www.cve.org/CVERecord?id=CVE-2006-5901">CVE-2006-5901</a></li>
+  <li><a href="https://www.cve.org/CVERecord?id=CVE-2005-3725">CVE-2005-3725</a></li>
 </ul>
 <p>Today’s services have an ever-changing architecture due to their scaling and redundancy needs. It is a mistake to think that a service will always
 have the same IP address. When it does change, the hardcoded IP will have to be modified too. This will have an impact on the product development,
 delivery, and deployment:</p>
 <ul>
-  <li> The developers will have to do a rapid fix every time this happens, instead of having an operation team change a configuration file. </li>
-  <li> It misleads to use the same address in every environment (dev, sys, qa, prod). </li>
+  <li>The developers will have to do a rapid fix every time this happens, instead of having an operation team change a configuration file.</li>
+  <li>It misleads to use the same address in every environment (dev, sys, qa, prod).</li>
 </ul>
 <p>Last but not least it has an effect on application security. Attackers might be able to decompile the code and thereby discover a potentially
 sensitive address. They can perform a Denial of Service attack on the service, try to get access to the system, or try to spoof the IP address to
@@ -17,8 +17,8 @@
 <h2>Ask Yourself Whether</h2>
 <p>The disclosed IP address is sensitive, e.g.:</p>
 <ul>
-  <li> Can give information to an attacker about the network topology. </li>
-  <li> It’s a personal (assigned to an identifiable person) IP address. </li>
+  <li>Can give information to an attacker about the network topology.</li>
+  <li>It’s a personal (assigned to an identifiable person) IP address.</li>
 </ul>
 <p>There is a risk if you answered yes to any of these questions.</p>
 <h2>Recommended Secure Coding Practices</h2>
@@ -38,20 +38,20 @@ <h2>Compliant Solution</h2>
 <h2>Exceptions</h2>
 <p>No issue is reported for the following cases because they are not considered sensitive:</p>
 <ul>
-  <li> Loopback addresses 127.0.0.0/8 in CIDR notation (from 127.0.0.0 to 127.255.255.255) </li>
-  <li> Broadcast address 255.255.255.255 </li>
-  <li> Non-routable address 0.0.0.0 </li>
-  <li> Strings of the form <code>2.5.&lt;number&gt;.&lt;number&gt;</code> as they <a href="https://en.wikipedia.org/wiki/Object_identifier">often
-  match Object Identifiers</a> (OID) </li>
-  <li> Addresses in the ranges 192.0.2.0/24, 198.51.100.0/24, 203.0.113.0/24, reserved for documentation purposes by <a
-  href="https://datatracker.ietf.org/doc/html/rfc5737">RFC 5737</a> </li>
-  <li> Addresses in the range 2001:db8::/32, reserved for documentation purposes by <a href="https://datatracker.ietf.org/doc/html/rfc3849">RFC
-  3849</a> </li>
+  <li>Loopback addresses 127.0.0.0/8 in CIDR notation (from 127.0.0.0 to 127.255.255.255)</li>
+  <li>Broadcast address 255.255.255.255</li>
+  <li>Non-routable address 0.0.0.0</li>
+  <li>Strings of the form <code>2.5.&lt;number&gt;.&lt;number&gt;</code> as they <a href="https://en.wikipedia.org/wiki/Object_identifier">often match
+  Object Identifiers</a> (OID)</li>
+  <li>Addresses in the ranges 192.0.2.0/24, 198.51.100.0/24, 203.0.113.0/24, reserved for documentation purposes by <a
+  href="https://datatracker.ietf.org/doc/html/rfc5737">RFC 5737</a></li>
+  <li>Addresses in the range 2001:db8::/32, reserved for documentation purposes by <a href="https://datatracker.ietf.org/doc/html/rfc3849">RFC
+  3849</a></li>
 </ul>
 <h2>See</h2>
 <ul>
-  <li> OWASP - <a href="https://owasp.org/Top10/A01_2021-Broken_Access_Control/">Top 10 2021 Category A1 - Broken Access Control</a> </li>
-  <li> OWASP - <a href="https://owasp.org/www-project-top-ten/2017/A3_2017-Sensitive_Data_Exposure">Top 10 2017 Category A3 - Sensitive Data
-  Exposure</a> </li>
+  <li>OWASP - <a href="https://owasp.org/Top10/A01_2021-Broken_Access_Control/">Top 10 2021 Category A1 - Broken Access Control</a></li>
+  <li>OWASP - <a href="https://owasp.org/www-project-top-ten/2017/A3_2017-Sensitive_Data_Exposure">Top 10 2017 Category A3 - Sensitive Data
+  Exposure</a></li>
 </ul>
 
diff --git a/sonar-scala-plugin/src/main/resources/org/sonar/l10n/scala/rules/scala/S134.html b/sonar-scala-plugin/src/main/resources/org/sonar/l10n/scala/rules/scala/S134.html
@@ -5,7 +5,7 @@ <h2>Why is this an issue?</h2>
 readability and maintainability, and it also complicates the testing process.</p>
 <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>
+  <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/sonar-scala-plugin/src/main/resources/org/sonar/l10n/scala/rules/scala/S1481.html b/sonar-scala-plugin/src/main/resources/org/sonar/l10n/scala/rules/scala/S1481.html
@@ -5,16 +5,16 @@ <h2>Why is this an issue?</h2>
 <h3>What is the potential impact?</h3>
 <p>Having unused local variables in your code can lead to several issues:</p>
 <ul>
-  <li> <strong>Decreased Readability</strong>: 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> <strong>Misunderstanding</strong>: 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> <strong>Potential for Bugs</strong>: 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> <strong>Maintenance Issues</strong>: 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> <strong>Memory Usage</strong>: 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>
+  <li><strong>Decreased Readability</strong>: 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><strong>Misunderstanding</strong>: 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><strong>Potential for Bugs</strong>: 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><strong>Maintenance Issues</strong>: 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><strong>Memory Usage</strong>: 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>
diff --git a/sonar-scala-plugin/src/main/resources/org/sonar/l10n/scala/rules/scala/S1763.html b/sonar-scala-plugin/src/main/resources/org/sonar/l10n/scala/rules/scala/S1763.html
@@ -18,6 +18,6 @@ <h3>Compliant solution</h3>
 </pre>
 <h2>Resources</h2>
 <ul>
-  <li> CWE - <a href="https://cwe.mitre.org/data/definitions/561">CWE-561 - Dead Code</a> </li>
+  <li>CWE - <a href="https://cwe.mitre.org/data/definitions/561">CWE-561 - Dead Code</a></li>
 </ul>
 
diff --git a/sonar-scala-plugin/src/main/resources/org/sonar/l10n/scala/rules/scala/S1764.html b/sonar-scala-plugin/src/main/resources/org/sonar/l10n/scala/rules/scala/S1764.html
diff --git a/sonar-scala-plugin/src/main/resources/org/sonar/l10n/scala/rules/scala/S1871.html b/sonar-scala-plugin/src/main/resources/org/sonar/l10n/scala/rules/scala/S1871.html
diff --git a/sonar-scala-plugin/src/main/resources/org/sonar/l10n/scala/rules/scala/S2068.html b/sonar-scala-plugin/src/main/resources/org/sonar/l10n/scala/rules/scala/S2068.html
diff --git a/sonar-scala-plugin/src/main/resources/org/sonar/l10n/scala/rules/scala/S2068.json b/sonar-scala-plugin/src/main/resources/org/sonar/l10n/scala/rules/scala/S2068.json
diff --git a/sonar-scala-plugin/src/main/resources/org/sonar/l10n/scala/rules/scala/S3776.html b/sonar-scala-plugin/src/main/resources/org/sonar/l10n/scala/rules/scala/S3776.html
