Run rules-api update (#1087)

Co-authored-by: Rudy Regazzoni <110470341+rudy-regazzoni-sonarsource@users.noreply.github.com>

php-checks/src/main/resources/org/sonar/l10n/php/rules/php/NoSonar.json

@@ -1,6 +1,12 @@
 {
   "title": "Track uses of \"NOSONAR\" comments",
   "type": "CODE_SMELL",
+  "code": {
+    "impacts": {
+      "MAINTAINABILITY": "MEDIUM"
+    },
+    "attribute": "CLEAR"
+  },
   "status": "ready",
   "remediation": {
     "func": "Constant\/Issue",

php-checks/src/main/resources/org/sonar/l10n/php/rules/php/S100.html

@@ -1,26 +1,30 @@
 <h2>Why is this an issue?</h2>
-<p>Shared naming conventions allow teams to collaborate efficiently. This rule checks that all function names match a provided regular expression.</p>
-<h3>Noncompliant code example</h3>
-<p>With default provided regular expression: <code>^[a-z][a-zA-Z0-9]*$</code>:</p>
+<p>Shared naming conventions allow teams to collaborate efficiently.</p>
+<p>This rule raises an issue when a function name does not match a provided regular expression.</p>
+<p>For example, with the default provided regular expression <code>^[a-z][a-zA-Z0-9]*$</code>, the function:</p>
 <pre>
-function DoSomething(){...}
+function DoSomething(){ // Noncompliant
+    // ...
+}
 </pre>
-<h3>Compliant solution</h3>
+<p>should be renamed to</p>
 <pre>
-function doSomething(){...}
+function doSomething(){
+    // ...
+}
 </pre>
 <h3>Exceptions</h3>
 <p>Methods with an <code>@inheritdoc</code> annotation, as well as magic methods (<code>__construct()</code>, <code>__destruct()</code>,
 <code>__call()</code>, <code>__callStatic()</code>, <code>__get()</code>, <code>__set()</code>, <code>__isset()</code>, <code>__unset()</code>,
 <code>__sleep()</code>, <code>__wakeup()</code>, <code>__toString()</code>, <code>__invoke()</code>, <code>__set_state()</code>,
 <code>__clone()</code>, <code>__debugInfo()</code>) are ignored.</p>
 <pre>
-function __construct(){...}
-function __destruct(){...}
+function __construct(){...} // Compliant by exception
+function __destruct(){...}  // Compliant by exception
 
 /**
  * {@inheritdoc}
  */
-function myFunc(){...}
+function myFunc(){...}      // Compliant by exception
 </pre>
 

php-checks/src/main/resources/org/sonar/l10n/php/rules/php/S100.json

@@ -1,6 +1,12 @@
 {
-  "title": "Method and function names should comply with a naming convention",
+  "title": "Function names should comply with a naming convention",
   "type": "CODE_SMELL",
+  "code": {
+    "impacts": {
+      "MAINTAINABILITY": "LOW"
+    },
+    "attribute": "IDENTIFIABLE"
+  },
   "status": "ready",
   "remediation": {
     "func": "Constant\/Issue",

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

@@ -1,12 +1,11 @@
 <h2>Why is this an issue?</h2>
-<p>Shared coding conventions allow teams to collaborate effectively. This rule allows to check that all class names match a provided regular
-expression.</p>
-<h3>Noncompliant code example</h3>
-<p>With default provided regular expression <code>^[A-Z][a-zA-Z0-9]*$</code>:</p>
+<p>Shared naming conventions allow teams to collaborate efficiently.</p>
+<p>This rule raises an issue when a class name does not match a provided regular expression.</p>
+<p>For example, with the default provided regular expression <code>^[A-Z][a-zA-Z0-9]*$</code>, the class:</p>
 <pre>
-class my_class {...}
+class my_class {...} // Noncompliant
 </pre>
-<h3>Compliant solution</h3>
+<p>should be renamed to</p>
 <pre>
 class MyClass {...}
 </pre>

php-checks/src/main/resources/org/sonar/l10n/php/rules/php/S101.json

@@ -1,6 +1,12 @@
 {
   "title": "Class names should comply with a naming convention",
   "type": "CODE_SMELL",
+  "code": {
+    "impacts": {
+      "MAINTAINABILITY": "LOW"
+    },
+    "attribute": "IDENTIFIABLE"
+  },
   "status": "ready",
   "remediation": {
     "func": "Constant\/Issue",

php-checks/src/main/resources/org/sonar/l10n/php/rules/php/S103.html

@@ -1,3 +1,3 @@
 <h2>Why is this an issue?</h2>
-<p>Having to scroll horizontally makes it harder to get a quick overview and understanding of any piece of code.</p>
+<p>Scrolling horizontally to see a full line of code lowers the code readability.</p>
 

php-checks/src/main/resources/org/sonar/l10n/php/rules/php/S103.json

@@ -1,6 +1,12 @@
 {
   "title": "Lines should not be too long",
   "type": "CODE_SMELL",
+  "code": {
+    "impacts": {
+      "MAINTAINABILITY": "MEDIUM"
+    },
+    "attribute": "FORMATTED"
+  },
   "status": "ready",
   "remediation": {
     "func": "Constant\/Issue",

php-checks/src/main/resources/org/sonar/l10n/php/rules/php/S104.html

@@ -1,5 +1,5 @@
 <h2>Why is this an issue?</h2>
-<p>A source file that grows too much tends to aggregate too many responsibilities and inevitably becomes harder to understand and therefore to
-maintain. Above a specific threshold, it is strongly advised to refactor it into smaller pieces of code which focus on well defined tasks. Those
-smaller files will not only be easier to understand but also probably easier to test.</p>
+<p>When a source file grows too much, it can accumulate numerous responsibilities and become challenging to understand and maintain.</p>
+<p>Above a specific threshold, refactor the file into smaller files whose code focuses on well-defined tasks. Those smaller files will be easier to
+understand and test.</p>
 

php-checks/src/main/resources/org/sonar/l10n/php/rules/php/S104.json

@@ -1,6 +1,12 @@
 {
   "title": "Files should not have too many lines of code",
   "type": "CODE_SMELL",
+  "code": {
+    "impacts": {
+      "MAINTAINABILITY": "MEDIUM"
+    },
+    "attribute": "FOCUSED"
+  },
   "status": "ready",
   "remediation": {
     "func": "Constant\/Issue",

php-checks/src/main/resources/org/sonar/l10n/php/rules/php/S1045.json

@@ -1,6 +1,12 @@
 {
   "title": "All \"catch\" blocks should be able to catch exceptions",
   "type": "BUG",
+  "code": {
+    "impacts": {
+      "RELIABILITY": "MEDIUM"
+    },
+    "attribute": "LOGICAL"
+  },
   "status": "ready",
   "remediation": {
     "func": "Constant\/Issue",

php-checks/src/main/resources/org/sonar/l10n/php/rules/php/S105.html

@@ -1,4 +1,5 @@
 <h2>Why is this an issue?</h2>
-<p>Developers should not need to configure the tab width of their text editors in order to be able to read source code.</p>
-<p>So the use of the tabulation character must be banned.</p>
+<p>The tab width can differ from one development environment to another. Using tabs may require other developers to configure their environment (text
+editor, preferences, etc.) to read source code.</p>
+<p>That is why using spaces is preferable.</p>
 

php-checks/src/main/resources/org/sonar/l10n/php/rules/php/S105.json

@@ -1,6 +1,12 @@
 {
   "title": "Tabulation characters should not be used",
   "type": "CODE_SMELL",
+  "code": {
+    "impacts": {
+      "MAINTAINABILITY": "LOW"
+    },
+    "attribute": "FORMATTED"
+  },
   "status": "ready",
   "remediation": {
     "func": "Constant\/Issue",

php-checks/src/main/resources/org/sonar/l10n/php/rules/php/S1066.json

@@ -1,6 +1,12 @@
 {
   "title": "Collapsible \"if\" statements should be merged",
   "type": "CODE_SMELL",
+  "code": {
+    "impacts": {
+      "MAINTAINABILITY": "MEDIUM"
+    },
+    "attribute": "CLEAR"
+  },
   "status": "ready",
   "remediation": {
     "func": "Constant\/Issue",

php-checks/src/main/resources/org/sonar/l10n/php/rules/php/S1067.json

@@ -1,6 +1,12 @@
 {
   "title": "Expressions should not be too complex",
   "type": "CODE_SMELL",
+  "code": {
+    "impacts": {
+      "MAINTAINABILITY": "HIGH"
+    },
+    "attribute": "FOCUSED"
+  },
   "status": "ready",
   "remediation": {
     "func": "Linear with offset",

php-checks/src/main/resources/org/sonar/l10n/php/rules/php/S1068.json

@@ -1,6 +1,12 @@
 {
   "title": "Unused \"private\" fields should be removed",
   "type": "CODE_SMELL",
+  "code": {
+    "impacts": {
+      "MAINTAINABILITY": "MEDIUM"
+    },
+    "attribute": "CLEAR"
+  },
   "status": "ready",
   "remediation": {
     "func": "Constant\/Issue",

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

@@ -1,17 +1,42 @@
 <h2>Why is this an issue?</h2>
-<p>A long parameter list can indicate that a new structure should be created to wrap the numerous parameters or that the function is doing too many
-things.</p>
-<h3>Noncompliant code example</h3>
-<p>With a maximum number of 4 parameters:</p>
+<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
+position.</p>
 <pre>
-function doSomething($param1, $param2, $param3, $param4, $param5) {
-...
+function setCoordinates($x1, $y1, $z1, $x2, $y2, $z2) { // Noncompliant
+    // ...
 }
 </pre>
-<h3>Compliant solution</h3>
+<p>The solution can be to:</p>
+<ul>
+  <li> Split the function into smaller ones </li>
+</ul>
 <pre>
-function doSomething($param1, $param2, $param3, $param4) {
-...
+// Each function does a part of what the original setCoordinates function was doing, so confusion risks are lower
+function setOrigin(int $x, int $y, int $z) {
+   // ...
+}
+
+function setSize(int $width, int $height, float $depth) {
+   // ...
+}
+</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>
+</ul>
+<pre>
+class Point
+{
+    // In geometry, Point is a logical structure to group data
+    public function __construct(
+        public int $x,
+        public int $y,
+        public int $z
+    ) {}
+}
+
+function setCoordinates(Point $p1, Point $p2) {
+    // ...
 }
 </pre>
+<p>This rule raises an issue when a function has more parameters than the provided threshold.</p>
 

php-checks/src/main/resources/org/sonar/l10n/php/rules/php/S107.json

@@ -1,6 +1,12 @@
 {
   "title": "Functions should not have too many parameters",
   "type": "CODE_SMELL",
+  "code": {
+    "impacts": {
+      "MAINTAINABILITY": "MEDIUM"
+    },
+    "attribute": "FOCUSED"
+  },
   "status": "ready",
   "remediation": {
     "func": "Constant\/Issue",

php-checks/src/main/resources/org/sonar/l10n/php/rules/php/S1075.json

@@ -1,6 +1,12 @@
 {
   "title": "URIs should not be hardcoded",
   "type": "CODE_SMELL",
+  "code": {
+    "impacts": {
+      "MAINTAINABILITY": "LOW"
+    },
+    "attribute": "CONVENTIONAL"
+  },
   "status": "ready",
   "remediation": {
     "func": "Constant\/Issue",

php-checks/src/main/resources/org/sonar/l10n/php/rules/php/S108.html

@@ -1,9 +1,10 @@
 <h2>Why is this an issue?</h2>
-<p>Most of the time a block of code is empty when a piece of code is really missing. So such empty block must be either filled or removed.</p>
-<h3>Noncompliant code example</h3>
+<p>An empty code block is confusing. It will require some effort from maintainers to determine if it is intentional or indicates the implementation is
+incomplete.</p>
 <pre>
-for ($i = 0; $i &lt; 42; $i++){}  // Empty on purpose or missing piece of code ?
+for ($i = 0; $i &lt; 42; $i++){}  // Noncompliant: is the block empty on purpose, or is code missing?
 </pre>
+<p>Removing or filling the empty code blocks takes away ambiguity and generally results in a more straightforward and less surprising code.</p>
 <h3>Exceptions</h3>
-<p>When a block contains a comment, this block is not considered to be empty.</p>
+<p>The rule ignores code blocks that contain comments.</p>
 

php-checks/src/main/resources/org/sonar/l10n/php/rules/php/S108.json

@@ -1,6 +1,12 @@
 {
   "title": "Nested blocks of code should not be left empty",
   "type": "CODE_SMELL",
+  "code": {
+    "impacts": {
+      "MAINTAINABILITY": "MEDIUM"
+    },
+    "attribute": "CLEAR"
+  },
   "status": "ready",
   "remediation": {
     "func": "Constant\/Issue",

php-checks/src/main/resources/org/sonar/l10n/php/rules/php/S110.html

@@ -1,7 +1,11 @@
 <h2>Why is this an issue?</h2>
-<p>Inheritance is certainly one of the most valuable concepts in object-oriented programming. It’s a way to compartmentalize and reuse code by
-creating collections of attributes and behaviors called classes which can be based on previously created classes. But abusing this concept by creating
-a deep inheritance tree can lead to very complex and unmaintainable source code. Most of the time a too deep inheritance tree is due to bad object
-oriented design which has led to systematically use 'inheritance' when for instance 'composition' would suit better.</p>
-<p>This rule raises an issue when the inheritance tree, starting from <code>Object</code> has a greater depth than is allowed.</p>
+<p>Inheritance is one of the most valuable concepts in object-oriented programming. It’s a way to categorize and reuse code by creating collections of
+attributes and behaviors called classes, which can be based on previously created classes.</p>
+<p>But abusing this concept by creating a deep inheritance tree can lead to complex and unmaintainable source code. Often, an inheritance tree
+becoming too deep is the symptom of systematic use of "inheritance" when other approaches like "composition" would be better suited.</p>
+<p>This rule raises an issue when the inheritance tree has a greater depth than is allowed.</p>
+<h2>Resources</h2>
+<h3>Documentation</h3>
+<p><a href="https://en.wikipedia.org/wiki/Composition_over_inheritance">Composition over inheritance: difference between composition and inheritance
+in object-oriented programming</a></p>
 

php-checks/src/main/resources/org/sonar/l10n/php/rules/php/S110.json

@@ -1,6 +1,12 @@
 {
   "title": "Inheritance tree of classes should not be too deep",
   "type": "CODE_SMELL",
+  "code": {
+    "impacts": {
+      "MAINTAINABILITY": "MEDIUM"
+    },
+    "attribute": "FOCUSED"
+  },
   "status": "ready",
   "remediation": {
     "func": "Linear with offset",

php-checks/src/main/resources/org/sonar/l10n/php/rules/php/S1105.json

@@ -1,6 +1,12 @@
 {
   "title": "An open curly brace should be located at the end of a line",
   "type": "CODE_SMELL",
+  "code": {
+    "impacts": {
+      "MAINTAINABILITY": "LOW"
+    },
+    "attribute": "FORMATTED"
+  },
   "status": "ready",
   "remediation": {
     "func": "Constant\/Issue",

php-checks/src/main/resources/org/sonar/l10n/php/rules/php/S1106.json

@@ -1,6 +1,12 @@
 {
   "title": "An open curly brace should be located at the beginning of a line",
   "type": "CODE_SMELL",
+  "code": {
+    "impacts": {
+      "MAINTAINABILITY": "LOW"
+    },
+    "attribute": "FORMATTED"
+  },
   "status": "ready",
   "remediation": {
     "func": "Constant\/Issue",

php-checks/src/main/resources/org/sonar/l10n/php/rules/php/S1109.json

@@ -1,6 +1,12 @@
 {
   "title": "A close curly brace should be located at the beginning of a line",
   "type": "CODE_SMELL",
+  "code": {
+    "impacts": {
+      "MAINTAINABILITY": "LOW"
+    },
+    "attribute": "FORMATTED"
+  },
   "status": "ready",
   "remediation": {
     "func": "Constant\/Issue",

php-checks/src/main/resources/org/sonar/l10n/php/rules/php/S1110.json

@@ -1,6 +1,12 @@
 {
   "title": "Redundant pairs of parentheses should be removed",
   "type": "CODE_SMELL",
+  "code": {
+    "impacts": {
+      "MAINTAINABILITY": "MEDIUM"
+    },
+    "attribute": "CLEAR"
+  },
   "status": "ready",
   "remediation": {
     "func": "Constant\/Issue",