* Revert "SONARGO-393 Modify rule S4423 for Go: remove examples for HTTP server…"
This reverts commit e7c5865c645d1d0268b89a1c9e6ec005c056545e.
* Adjusted text about go version
In some cases, the `rule.adoc` at root of a rule is never included
anywhere and thus is dead code.
It's a maintenance cost by itself, but also it misses opportunities to
inline code that seems used by two documents when in fact only one
document is actually rendered. And this missed opportunity, in turn,
stops us from applying the correct language tag on the code samples.
## Review
A dedicated reviewer checked the rule description successfully for:
- [ ] logical errors and incorrect information
- [ ] information gaps and missing content
- [ ] text style and tone
- [ ] PR summary and labels follow [the
guidelines](https://github.com/SonarSource/rspec/#to-modify-an-existing-rule)
## Review
A dedicated reviewer checked the rule description successfully for:
- [x] logical errors and incorrect information
- [x] information gaps and missing content
- [x] text style and tone
- [x] PR summary and labels follow [the
guidelines](https://github.com/SonarSource/rspec/#to-modify-an-existing-rule)
## Review
A dedicated reviewer checked the rule description successfully for:
- [ ] logical errors and incorrect information
- [ ] information gaps and missing content
- [ ] text style and tone
- [ ] PR summary and labels follow [the
guidelines](https://github.com/SonarSource/rspec/#to-modify-an-existing-rule)
Improvement identified in #2790.
Add a prefix to the diff-id when it is used multiple times in different
"how to fix it in XYZ" sections to avoid ambiguity and pedantically
follow the spec:
> A single and unique diff-id should be used only once for each type of
code example as shown in the description of a rule.
Obvious typos around `diff-type` were fixed.
An obvious extra use of diff blocks was removed.
Improvement identified in #2790.
Add a prefix to the diff-id when it is used multiple times in different
"how to fix it in XYZ" sections to avoid ambiguity and pedantically
follow the spec:
> A single and unique diff-id should be used only once for each type of
code example as shown in the description of a rule.
Obvious typos around `diff-id` were fixed.
Improvement identified in #2790.
Add a prefix to the diff-id when it is used multiple times in different
"how to fix it in XYZ" sections to avoid ambiguity and pedantically
follow the spec:
> A single and unique diff-id should be used only once for each type of
code example as shown in the description of a rule.
Obvious typos around `diff-type` were fixed.
Improvement identified in #2790.
Add a prefix to the diff-id when it is used multiple times in different
"how to fix it in XYZ" sections to avoid ambiguity and pedantically
follow the spec:
> A single and unique diff-id should be used only once for each type of
code example as shown in the description of a rule.
Obvious typos around `diff-type` were fixed.
Improvement identified in #2790.
Add a prefix to the diff-id when it is used multiple times in different
"how to fix it in XYZ" sections to avoid ambiguity and pedantically
follow the spec:
> A single and unique diff-id should be used only once for each type of
code example as shown in the description of a rule.
Improvement identified in #2790.
Add a prefix to the diff-id when it is used multiple times in different
"how to fix it in XYZ" sections to avoid ambiguity and pedantically
follow the spec:
> A single and unique diff-id should be used only once for each type of
code example as shown in the description of a rule.
Obvious typos around `diff-id` were fixed.
Improvement identified in #2790.
Add a prefix to the diff-id when it is used multiple times in different
"how to fix it in XYZ" sections to avoid ambiguity and pedantically
follow the spec:
> A single and unique diff-id should be used only once for each type of
code example as shown in the description of a rule.
Improvement identified in #2790.
Add a prefix to the diff-id when it is used multiple times in different
"how to fix it in XYZ" sections to avoid ambiguity and pedantically
follow the spec:
> A single and unique diff-id should be used only once for each type of
code example as shown in the description of a rule.
Obvious typos around `diff-type` and `diff-id` were fixed.
## Review
A dedicated reviewer checked the rule description successfully for:
- [x] logical errors and incorrect information
- [x] information gaps and missing content
- [x] text style and tone
- [x] PR summary and labels follow [the
guidelines](https://github.com/SonarSource/rspec/#to-modify-an-existing-rule)
When an include is not surrounded by empty lines, its content is inlined
on the same line as the adjacent content. That can lead to broken tags
and other display issues.
This PR fixes all such includes and introduces a validation step that
forbids introducing the same problem again.
Inline adoc files when they are included exactly once.
Also fix language tags because this inlining gives us better information
on what language the code is written in.
