Create rule S8196: Single-method interface names should follow Go naming conventions (#5757)

* Create rule S8196

* Update rules/S8196/go/rule.adoc in PR #5757

* Update rules/S8196/go/metadata.json in PR #5757

* Update metadata

* Update rule.adoc

---------

Co-authored-by: denis-troller <[email protected]>
Co-authored-by: denis-troller <[email protected]>
Co-authored-by: yassin-kammoun-sonarsouce <[email protected]>
Co-authored-by: Sébastien Marichal <[email protected]>

Author: 4 people

rules/S8196/go/metadata.json

@@ -0,0 +1,26 @@
+{
+  "title": "Single-method interface names should follow Go naming conventions",
+  "type": "CODE_SMELL",
+  "status": "ready",
+  "remediation": {
+    "func": "Constant/Issue",
+    "constantCost": "5 min"
+  },
+  "tags": [
+    "convention"
+  ],
+  "defaultSeverity": "Minor",
+  "ruleSpecification": "RSPEC-8196",
+  "sqKey": "S8196",
+  "scope": "All",
+  "defaultQualityProfiles": [
+    "Sonar way"
+  ],
+  "quickfix": "unknown",
+  "code": {
+    "impacts": {
+      "MAINTAINABILITY": "LOW"
+    },
+    "attribute": "CONVENTIONAL"
+  }
+}

rules/S8196/go/rule.adoc

@@ -0,0 +1,48 @@
+This is an issue when a single-method interface doesn't use the method name plus an "-er" suffix or similar modification to construct an agent noun.
+
+== Why is this an issue?
+
+Go has established naming conventions for interfaces, particularly single-method interfaces. According to the official Go documentation "Effective Go", single-method interfaces should be named by taking the method name and adding an "-er" suffix or similar modification to create an agent noun.
+
+This convention serves several important purposes:
+
+* **Predictability**: Developers can quickly understand what an interface does just by looking at its name
+* **Consistency**: Following established patterns makes codebases more uniform and easier to navigate
+* **Readability**: Agent nouns like `Reader`, `Writer`, `Formatter` immediately convey the interface's purpose
+* **Community standards**: Adhering to Go conventions makes code more familiar to other Go developers
+
+When interfaces don't follow this pattern, they become less intuitive. For example, `FileRead` doesn't immediately suggest it's an interface, while `Reader` clearly indicates both the action and that it's likely an interface following Go conventions.
+
+=== What is the potential impact?
+
+Not following Go naming conventions reduces code readability and makes it harder for developers to understand the codebase quickly. It can also make the code feel inconsistent with standard Go libraries and community practices, potentially confusing team members who expect conventional naming patterns.
+
+== How to fix it
+
+Rename the interface to follow Go conventions by using the method name plus an "-er" suffix or similar agent noun construction.
+
+=== Code examples
+
+==== Noncompliant code example
+
+[source,go,diff-id=1,diff-type=noncompliant]
+----
+type FileRead interface {
+    Read([]byte) (int, error)
+} // Noncompliant
+----
+
+==== Compliant solution
+
+[source,go,diff-id=1,diff-type=compliant]
+----
+type FileReader interface {
+    Read([]byte) (int, error)
+}
+----
+
+== Resources
+
+=== Documentation
+
+ * Effective Go - Interface names - https://go.dev/doc/effective_go#interface-names[Official Go documentation explaining interface naming conventions]

rules/S8196/metadata.json

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