Create rule S8317: Collection literals should be used instead of explicit constructors

rules/S8317/groovy/metadata.json

@@ -0,0 +1,27 @@
+{
+  "title": "Collection literals should be used instead of explicit constructors",
+  "type": "CODE_SMELL",
+  "status": "ready",
+  "remediation": {
+    "func": "Constant/Issue",
+    "constantCost": "2 min"
+  },
+  "tags": [
+    "convention",
+    "groovy"
+  ],
+  "defaultSeverity": "Critical",
+  "ruleSpecification": "RSPEC-8317",
+  "sqKey": "S8317",
+  "scope": "All",
+  "defaultQualityProfiles": [
+    "Sonar way"
+  ],
+  "quickfix": "unknown",
+  "code": {
+    "impacts": {
+      "MAINTAINABILITY": "HIGH"
+    },
+    "attribute": "CONVENTIONAL"
+  }
+}

rules/S8317/groovy/rule.adoc

@@ -0,0 +1,59 @@
+This rule raises an issue when explicit no-argument constructors are used to create collections like `new ArrayList()`, `new HashMap()`, or `new HashSet()`.
+
+== Why is this an issue?
+
+Groovy provides concise collection literals that are more idiomatic and readable than explicit constructor calls. Using collection literals is a fundamental aspect of writing idiomatic Groovy code.
+
+Explicit constructor calls like `new ArrayList()` are verbose and follow Java conventions rather than embracing Groovy's more expressive syntax. Collection literals not only reduce code verbosity but also make the intent clearer and the code more maintainable.
+
+For example, `[]` immediately communicates "empty list" while `new ArrayList()` requires the reader to understand the constructor call and its implications. Similarly, `[:]` clearly represents an empty map, while `new HashMap()` is more verbose and less intuitive.
+
+Groovy's collection literals also provide consistency across different collection types, making the codebase more uniform and easier to read for developers familiar with Groovy idioms.
+
+=== What is the potential impact?
+
+Using explicit constructors instead of collection literals makes the code more verbose and less idiomatic. This reduces code readability and maintainability, especially for developers familiar with Groovy conventions. While functionally equivalent, the verbose syntax can make the codebase harder to scan and understand quickly.
+
+== How to fix it
+
+Replace explicit constructor calls with Groovy collection literals. Use `[]` for lists, `[:]` for maps, and type coercion with `as` for specific collection types.
+
+=== Code examples
+
+==== Noncompliant code example
+
+[source,groovy,diff-id=1,diff-type=noncompliant]
+----
+def list = new ArrayList() // Noncompliant
+def map = new HashMap() // Noncompliant
+def set = new HashSet() // Noncompliant
+def queue = new LinkedList() // Noncompliant
+def sortedSet = new TreeSet() // Noncompliant
+def stack = new Stack() // Noncompliant
+----
+
+==== Compliant solution
+
+[source,groovy,diff-id=1,diff-type=compliant]
+----
+def list = []
+def map = [:]
+def set = [] as Set
+def queue = [] as Queue
+def sortedSet = [] as SortedSet
+def stack = [] as Stack
+----
+
+== Resources
+
+=== Documentation
+
+ * Groovy Collections Documentation - https://groovy-lang.org/syntax.html#_lists[Official Groovy documentation on collection literals and syntax]
+
+ * CodeNarc Groovyism Rules - https://codenarc.org/codenarc-rules-groovyism.html[CodeNarc rules covering Groovy idiomatic usage and best practices]
+
+=== Related rules
+
+ * S7498 - https://rules.sonarsource.com/python/RSPEC-7498/[Python rule for preferring list literals over constructor calls]
+
+ * S7496 - https://rules.sonarsource.com/python/RSPEC-7496/[Python rule for preferring dict literals over constructor calls]

rules/S8317/metadata.json

@@ -0,0 +1,2 @@
+{
+}