SONARFLEX-173 Update rule metadata with clean code taxonomy attributes

flex-checks/src/main/resources/org/sonar/l10n/flex/rules/flex/ActionScript2.json

@@ -1,6 +1,12 @@
 {
   "title": "Statements, operators and keywords specific to ActionScript 2 should not be used",
   "type": "CODE_SMELL",
+  "code": {
+    "impacts": {
+      "MAINTAINABILITY": "MEDIUM"
+    },
+    "attribute": "CONVENTIONAL"
+  },
   "status": "ready",
   "remediation": {
     "func": "Constant\/Issue",

flex-checks/src/main/resources/org/sonar/l10n/flex/rules/flex/CommentRegularExpression.json

@@ -1,6 +1,12 @@
 {
   "title": "Track comments matching a regular expression",
   "type": "CODE_SMELL",
+  "code": {
+    "impacts": {
+      "MAINTAINABILITY": "MEDIUM"
+    },
+    "attribute": "CONVENTIONAL"
+  },
   "status": "ready",
   "remediation": {
     "func": "Constant\/Issue",

flex-checks/src/main/resources/org/sonar/l10n/flex/rules/flex/CommentedCode.json

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

flex-checks/src/main/resources/org/sonar/l10n/flex/rules/flex/FunctionComplexity.json

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

flex-checks/src/main/resources/org/sonar/l10n/flex/rules/flex/FunctionSinglePointOfExit.json

@@ -1,6 +1,12 @@
 {
   "title": "A function should have a single point of exit at the end of the function",
   "type": "CODE_SMELL",
+  "code": {
+    "impacts": {
+      "MAINTAINABILITY": "LOW"
+    },
+    "attribute": "CONVENTIONAL"
+  },
   "status": "ready",
   "remediation": {
     "func": "Constant\/Issue",

flex-checks/src/main/resources/org/sonar/l10n/flex/rules/flex/LineLength.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",

flex-checks/src/main/resources/org/sonar/l10n/flex/rules/flex/NonEmptyCaseWithoutBreak.json

@@ -1,6 +1,12 @@
 {
   "title": "Switch cases should end with an unconditional \"break\" statement",
   "type": "CODE_SMELL",
+  "code": {
+    "impacts": {
+      "MAINTAINABILITY": "HIGH"
+    },
+    "attribute": "CLEAR"
+  },
   "status": "ready",
   "remediation": {
     "func": "Constant\/Issue",

flex-checks/src/main/resources/org/sonar/l10n/flex/rules/flex/OneStatementPerLine.html

@@ -1,12 +1,11 @@
 <h2>Why is this an issue?</h2>
-<p>For better readability, do not put more than one statement on a single line.</p>
-<h3>Noncompliant code example</h3>
+<p>Putting multiple statements on a single line lowers the code readability and makes debugging the code more complex.</p>
 <pre>
-if(someCondition) doSomething();
+if (someCondition) doSomething(); // Noncompliant
 </pre>
-<h3>Compliant solution</h3>
+<p>Write one statement per line to improve readability.</p>
 <pre>
-if(someCondition) {
+if (someCondition) {
   doSomething();
 }
 </pre>

flex-checks/src/main/resources/org/sonar/l10n/flex/rules/flex/OneStatementPerLine.json

@@ -1,6 +1,12 @@
 {
   "title": "Statements should be on separate lines",
   "type": "CODE_SMELL",
+  "code": {
+    "impacts": {
+      "MAINTAINABILITY": "MEDIUM"
+    },
+    "attribute": "FORMATTED"
+  },
   "status": "ready",
   "remediation": {
     "func": "Constant\/Issue",

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

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

flex-checks/src/main/resources/org/sonar/l10n/flex/rules/flex/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",

flex-checks/src/main/resources/org/sonar/l10n/flex/rules/flex/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",

flex-checks/src/main/resources/org/sonar/l10n/flex/rules/flex/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",

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

@@ -1,17 +1,38 @@
 <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>
-public function addData(p1 : int, p2 : int, p3 : int, p4 : int, p5 : int): void  {
-...
+function setCoordinates(var x1, var y1, var z1, var x2, var y2, var 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>
-public function addData(p1 : int, p2 : int, p3 : int, p4 : int): void  {
-...
+// Each function does a part of what the original setCoordinates function was doing, so confusion risks are lower
+void setOrigin(var x, var y, var z) {
+   // ...
+}
+
+void setSize(var width, var height, var 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>
+struct Point { // In geometry, Point is a logical structure to group data
+    var x;
+    var y;
+    var z;
+};
+
+function setCoordinates(var p1, var p2) {
+    // ...
 }
 </pre>
+<p>This rule raises an issue when a function has more parameters than the provided threshold.</p>
 

flex-checks/src/main/resources/org/sonar/l10n/flex/rules/flex/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",

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

@@ -1,6 +1,6 @@
 <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 (var i:int = 0; i &lt; 42; i++){}  // Noncompliant
 
@@ -10,14 +10,7 @@ <h3>Noncompliant code example</h3>
     ...
 }
 </pre>
-<h3>Compliant solution</h3>
-<pre>
-for (var i:int = 0; i &lt; 42; i++);
-
-for (var i:int = 0; i &lt; 42; i++) {
-  trace(i);
-}
-</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>
 

flex-checks/src/main/resources/org/sonar/l10n/flex/rules/flex/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",

flex-checks/src/main/resources/org/sonar/l10n/flex/rules/flex/S1116.json

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

flex-checks/src/main/resources/org/sonar/l10n/flex/rules/flex/S1117.html

@@ -1,13 +1,12 @@
 <h2>Why is this an issue?</h2>
 <p>Overriding or shadowing a variable declared in an outer scope can strongly impact the readability, and therefore the maintainability, of a piece of
 code. Further, it could lead maintainers to introduce bugs because they think they’re using one variable but are really using another.</p>
-<h3>Noncompliant code example</h3>
 <pre>
 class Foo {
   public var myField:int;
 
   public function doSomething():String {
-    var myField:int = 0;
+    var myField:int = 0; /* Noncompliant */
     ...
   }
 }

flex-checks/src/main/resources/org/sonar/l10n/flex/rules/flex/S1117.json

@@ -1,6 +1,12 @@
 {
   "title": "Local variables should not shadow class fields",
   "type": "CODE_SMELL",
+  "code": {
+    "impacts": {
+      "MAINTAINABILITY": "MEDIUM"
+    },
+    "attribute": "CLEAR"
+  },
   "status": "ready",
   "remediation": {
     "func": "Constant\/Issue",

flex-checks/src/main/resources/org/sonar/l10n/flex/rules/flex/S1125.json

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

flex-checks/src/main/resources/org/sonar/l10n/flex/rules/flex/S1142.json

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

flex-checks/src/main/resources/org/sonar/l10n/flex/rules/flex/S1144.json

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

flex-checks/src/main/resources/org/sonar/l10n/flex/rules/flex/S115.json

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

flex-checks/src/main/resources/org/sonar/l10n/flex/rules/flex/S1151.json

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

flex-checks/src/main/resources/org/sonar/l10n/flex/rules/flex/S116.json

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