Clean code attributes and better descriptions complying with Sonar Coding rule guidelines

src/main/rules/GCI1/GCI1.json

@@ -1,5 +1,5 @@
 {
-  "title": "Avoid Spring repository call in loop or stream operations",
+  "title": "Spring repository should not be called in loop or stream operations",
   "type": "CODE_SMELL",
   "status": "ready",
   "remediation": {
@@ -9,8 +9,14 @@
   "tags": [
     "performance",
     "spring",
-    "eco-design",
+    "sustainability",
     "creedengo"
   ],
-  "defaultSeverity": "Minor"
+  "defaultSeverity": "Minor",
+  "code": {
+    "impacts": {
+      "RELIABILITY": "LOW"
+    },
+    "attribute": "EFFICIENT"
+  }
 }

src/main/rules/GCI1/java/GCI1.asciidoc

@@ -1,10 +1,16 @@
+:!sectids:
+
+== Why is this an issue?
+
 The use of Spring repository in a loop induces unnecessary calculations by the CPU and therefore superfluous energy consumption.
 Also, the use of Spring repository in a stream operation like "peek, forEach, forEachOrdered, map" induces unnecessary multiple access to the database instead of single batch call.
 
-== Non compliant Code Example
+== How to fix it
+=== Noncompliant code example
 
 [source,java]
 ----
+// Noncompliant
 private final List<Integer> ids = Arrays.asList(1, 2, 3, 4, 5, 6, 7, 8, 9, 10);
 
 List<Employee> employees = new ArrayList<>();
@@ -19,6 +25,7 @@ for (Integer id: ids) {
 
 [source,java]
 ----
+// Noncompliant
 List<Employee> employees = new ArrayList<>();
 Stream stream = Stream.of(1, 2, 3, 4, 5, 6, 7, 8, 9, 10);
 stream.forEach(id -> {
@@ -29,7 +36,7 @@ stream.forEach(id -> {
 });
 ----
 
-== Compliant Solution
+=== Compliant solution
 
 [source,java]
 ----
@@ -42,3 +49,7 @@ List<Employee> employees = employeeRepository.findAllById(ids);
 private final List<Integer> ids = Stream.of(1, 2, 3, 4, 5, 6, 7, 8, 9, 10).toList();
 List<Employee> employees = employeeRepository.findAllById(ids);
 ----
+
+== Resources
+
+Reference/Validation is unknown.

src/main/rules/GCI10/GCI10.json

@@ -1,14 +1,21 @@
 {
-  "title": "Avoid using unoptimized vector images",
+  "title": "Unoptimized vector images should be avoided",
   "type": "CODE_SMELL",
   "status": "ready",
   "remediation": {
     "func": "Constant\/Issue",
     "constantCost": "60min"
   },
   "tags": [
-    "eco-design",
-    "creedengo"
+    "sustainability",
+    "creedengo",
+    "performance"
   ],
-  "defaultSeverity": "Minor"
+  "defaultSeverity": "Minor",
+  "code": {
+    "impacts": {
+      "RELIABILITY": "LOW"
+    },
+    "attribute": "EFFICIENT"
+  }
 }

src/main/rules/GCI10/python/GCI10.asciidoc

@@ -1,9 +1,15 @@
+:!sectids:
+
+== Why is this an issue?
+
 SVG images generated by common drawing softwares contains unnecessary data: calc layer, metadata, namespaces and comments.
 
-== Non compliant Code Example
+== How to fix it
+=== Noncompliant code example
 
 [source,xml]
 ----
+<!-- Noncompliant -->
 <!-- Created with Inkscape (http://www.inkscape.org/) -->
 <svg
     width="210mm"
@@ -31,11 +37,15 @@ SVG images generated by common drawing softwares contains unnecessary data: calc
 </svg>
 ----
 
-== Compliant Solution
+=== Compliant solution
 
 [source,xml]
 ----
 <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 210 297" width="210mm" height="297mm">
     <circle cx="104.02724" cy="152.19028" r="73.177132" style="fill:#ff00ff;stroke-width:0.264583"/>
 </svg>
 ----
+
+== Resources
+
+- https://github.com/cnumr/best-practices/blob/main/chapters/BP_036_fr.md[CNumR best practices (3rd edition) BP_036]

src/main/rules/GCI11/GCI11.json

@@ -1,23 +1,23 @@
 {
-  "title": "Disallow multiple access of same DOM element.",
+  "title": "DOM manipulation should be limited",
   "type": "CODE_SMELL",
-  "code": {
-    "impacts": {
-      "MAINTAINABILITY": "MEDIUM"
-    },
-    "attribute": "EFFICIENT"
-  },
   "status": "ready",
   "remediation": {
     "func": "Constant\/Issue",
     "constantCost": "5min"
   },
   "tags": [
     "creedengo",
-    "eco-design",
+    "sustainability",
     "performance"
   ],
   "defaultSeverity": "Major",
+  "code": {
+    "impacts": {
+      "RELIABILITY": "MEDIUM"
+    },
+    "attribute": "EFFICIENT"
+  },
   "compatibleLanguages": [
     "JAVASCRIPT",
     "TYPESCRIPT"

src/main/rules/GCI11/javascript/GCI11.asciidoc

@@ -10,14 +10,19 @@ Assigning the DOM object to a variable not only improves performance but also en
 It makes the code more concise and self-explanatory.
 Developers reading the code can understand that the variable holds a reference to a specific DOM element, and its subsequent use is likely for multiple operations.
 
+== How to fix it
+=== Noncompliant code example
+
 Here's an example in JavaScript to illustrate this rule:
 
 [source,js,data-diff-id="2",data-diff-type="noncompliant"]
 ----
 const width = document.getElementById('block').clientWidth;
-const height = document.getElementById('block').clientHeight; // Non-compliant
+const height = document.getElementById('block').clientHeight; // Noncompliant
 ----
 
+=== Compliant solution
+
 [source,js,data-diff-id="1",data-diff-type="noncompliant"]
 ----
 const blockElement = document.getElementById('block'); // Compliant
@@ -32,5 +37,5 @@ In the second example, the DOM element reference is cached in the `blockElement`
 
 === Documentation
 
-- https://github.com/cnumr/best-practices/blob/main/chapters/BP_054_en.md[CNUMR best practices] - Reduce DOM access via JavaScript
+- https://github.com/cnumr/best-practices/blob/main/chapters/BP_054_en.md[CNumR best practices] - Reduce DOM access via JavaScript
 - https://developer.mozilla.org/en-US/docs/Learn/Performance/JavaScript#tips_for_writing_more_efficient_code[Mozilla Web Technology for Developers] - Tips for writing more efficient code

src/main/rules/GCI12/GCI12.json

@@ -1,23 +1,23 @@
 {
-  "title": "Disallow multiple style changes at once.",
+  "title": "Multiple style changes should be batched",
   "type": "CODE_SMELL",
-  "code": {
-    "impacts": {
-      "MAINTAINABILITY": "MEDIUM"
-    },
-    "attribute": "EFFICIENT"
-  },
   "status": "ready",
   "remediation": {
     "func": "Constant\/Issue",
     "constantCost": "10min"
   },
   "tags": [
     "creedengo",
-    "eco-design",
+    "sustainability",
     "performance"
   ],
   "defaultSeverity": "Major",
+  "code": {
+    "impacts": {
+      "RELIABILITY": "MEDIUM"
+    },
+    "attribute": "EFFICIENT"
+  },
   "compatibleLanguages": [
     "JAVASCRIPT",
     "TYPESCRIPT"

src/main/rules/GCI12/javascript/GCI12.asciidoc

@@ -10,17 +10,22 @@ Making multiple CSS changes in a single batch can trigger multiple reflows and r
 Reflows and repaints are resource-intensive operations that can lead to performance issues.
 Applying changes individually minimizes the number of reflows and repaints, improving overall page performance.
 
+== How to fix it
+=== Noncompliant code example
+
 Here's an example in JavaScript and CSS to illustrate this rule:
 
 [source,html,data-diff-id="3",data-diff-type="noncompliant"]
 ----
 <script>
   element.style.height = "800px";
-  element.style.width = "600px"; // Non-compliant
-  element.style.color = "red"; // Non-compliant
+  element.style.width = "600px"; // Noncompliant
+  element.style.color = "red"; // Noncompliant
 </script>
 ----
 
+=== Compliant solution
+
 [source,html,data-diff-id="10",data-diff-type="compliant"]
 ----
 <style>
@@ -42,4 +47,4 @@ In the first example, multiple CSS properties are set in a single batch, while i
 
 === Documentation
 
-- https://github.com/cnumr/best-practices/blob/main/chapters/BP_045_en.md[CNUMR best practices] - Modify several CSS properties at once
+- https://github.com/cnumr/best-practices/blob/main/chapters/BP_045_en.md[CNumR best practices] - Modify several CSS properties at once

src/main/rules/GCI13/GCI13.json

@@ -1,9 +1,9 @@
 {
-  "title": "Prefer API collections with pagination.",
+  "title": "API collections should be preferred with pagination",
   "type": "CODE_SMELL",
   "code": {
     "impacts": {
-      "MAINTAINABILITY": "MEDIUM"
+      "RELIABILITY": "MEDIUM"
     },
     "attribute": "EFFICIENT"
   },
@@ -14,7 +14,7 @@
   },
   "tags": [
     "creedengo",
-    "eco-design",
+    "sustainability",
     "nestjs",
     "performance"
   ],

src/main/rules/GCI13/javascript/GCI13.asciidoc

@@ -11,15 +11,20 @@ Pagination ensures that only the relevant data is transferred, conserving bandwi
 
 This rule is built for the https://nestjs.com[NestJS framework] but can work with a controller `@Controller()` and a decorated method `@Get()`.
 
+== How to fix it
+=== Noncompliant code example
+
 [source,typescript,data-diff-id="4",data-diff-type="noncompliant"]
 ----
 @Controller()
 class Test {
   @Get()
-  public find(): Promise<string[]> {} // Non-compliant
+  public find(): Promise<string[]> {} // Noncompliant
 }
 ----
 
+=== Compliant solution
+
 [source,typescript,data-diff-id="10",data-diff-type="compliant"]
 ----
 interface Pagination {
@@ -39,7 +44,7 @@ class Test {
 
 === Documentation
 
-- https://github.com/cnumr/best-practices/blob/main/chapters/BP_076_en.md[CNUMR best practices] - Avoid transferring large amounts of data for processing tasks
+- https://github.com/cnumr/best-practices/blob/main/chapters/BP_076_en.md[CNumR best practices] - Avoid transferring large amounts of data for processing tasks
 - https://github.com/ppetzold/nestjs-paginate[nestjs-paginate] - Pagination and filtering helper method using Nest.js framework
 
 === Articles & blog posts

src/main/rules/GCI2/GCI2.json

@@ -1,15 +1,21 @@
 {
-  "title": "Avoid multiple if-else statement",
+  "title": "Variables should not be used in multiple if...else statements",
   "type": "CODE_SMELL",
   "status": "ready",
   "remediation": {
     "func": "Constant\/Issue",
     "constantCost": "5min"
   },
   "tags": [
-    "eco-design",
+    "sustainability",
     "performance",
     "creedengo"
   ],
-  "defaultSeverity": "Minor"
+  "defaultSeverity": "Minor",
+  "code": {
+    "impacts": {
+      "RELIABILITY": "LOW"
+    },
+    "attribute": "EFFICIENT"
+  }
 }

src/main/rules/GCI2/java/GCI2.asciidoc

@@ -1,25 +1,28 @@
-If we are using too many conditional IF, ELSEIF or ELSE statements it will impact performance.
-We can think of using a switch statement instead of multiple if-else if possible, or refactor code
-to reduce number of IF, ELSEIF and ELSE statements. Sometimes called "complexity cyclomatic".
-Switch statement has a performance advantage over if – else.
-
-== Functional rules
-- one variable must be used maximum twice in IF / ELSEIF / ELSE statements at the same level - WARNINGs :
-- IF and ELSEIF statements use explicitly variable names !
-- ELSE statements use implicity variable names !
-- one variable must be used maximum twice in IF / ELSEIF / ELSE statements at differents hierarchical levels
-- we can assume that if one variable is used three times or more, we should :
-- use a SWITCH statement instead
-- or refactor the code if possible
-
-== Non compliant Code Example
-
-NON compliant, because `nb` is used 4 times :
-- 2 explicit times in IF statements
-- 2 implicit times in ELSE statements
+:!sectids:
+
+One variable should be used at most twice in `if...else if...else` statements:
+
+- variable is used explicitly in `if` and `else if` statements
+- variable is used implicitly in `else` statements
+
+== Why is this an issue?
+
+Performance is impacted by many conditional `if`, `else if` or `else` statements, which is sometimes called "cyclomatic complexity".
+
+Switch statement has a performance advantage over `if...else`.
+
+== How to fix it
+
+=== Noncompliant code example
+
+Code is noncompliant, because `nb` is used 4 times:
+
+- 3 times explicitly in `if` statements
+- 1 time implicitly in `else` statement
 
 [source,java]
 ----
+// Noncompliant
 int index = 1;
 int nb = 2;
 ...
@@ -35,9 +38,11 @@ if (nb == 0) {
 return nb;
 ----
 
-== Compliant Code Example
+=== Compliant solution
 
-SWITCH statement solution + refactor solution
+A switch statement can be used instead of multiple `if...else` if possible, or code can be refactored to reduce number of `if...else if...else` statements.
+
+With a `switch` statement:
 
 [source,java]
 ----
@@ -55,3 +60,7 @@ switch (nb) {
 }
 return nb;
 ----
+
+== Resources
+
+Reference/Validation is unknown.