51369b610e
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.
33 lines
851 B
Plaintext
33 lines
851 B
Plaintext
An empty {operationName} is generally considered bad practice and can lead to confusion, readability, and maintenance issues.
|
|
Empty {operationName}s bring no functionality and are misleading to others as they might think the {operationName} implementation fulfills a specific and identified requirement.
|
|
|
|
Such {operationName}s should be avoided and possibly removed.
|
|
|
|
include::{emptyCode}[]
|
|
|
|
However, there are some cases where a {operationName} needs to be empty. In those cases, it is essential to minimize confusion and enhance clarity.
|
|
|
|
Here are a few examples:
|
|
|
|
* The {operationName} will never be implemented.
|
|
+
|
|
--
|
|
|
|
include::{notsupportedCode}[]
|
|
|
|
--
|
|
* The {operationName} will be implemented in the future.
|
|
+
|
|
--
|
|
|
|
include::{notimplementedCode}[]
|
|
|
|
--
|
|
* The {operationName} implementation is empty intentionally.
|
|
+
|
|
--
|
|
|
|
include::{commentCode}[]
|
|
|
|
--
|