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.
42 lines
887 B
Plaintext
42 lines
887 B
Plaintext
== Why is this an issue?
|
|
|
|
PL/I, unlike many other programming languages, does not reserve any word's usage.
|
|
|
|
This implies that it is syntaxically valid to use the keyword ``++IF++`` as variable names for instance.
|
|
|
|
But doing so results in confusing code which is hard to read, especially in editors without proper PL/I syntax highlighting support.
|
|
|
|
=== Noncompliant code example
|
|
|
|
[source,pli]
|
|
----
|
|
foo: proc options(main);
|
|
declare if fixed decimal init (42); /* Non-Compliant */
|
|
|
|
if if = 42 then do; /* Cconfusing */
|
|
put list ('if = 42');
|
|
end;
|
|
|
|
go to goto; /* Confusing */
|
|
|
|
goto: /* Non-Compliant */
|
|
;
|
|
end;
|
|
----
|
|
|
|
ifdef::env-github,rspecator-view[]
|
|
|
|
'''
|
|
== Implementation Specification
|
|
(visible only on this page)
|
|
|
|
include::../message.adoc[]
|
|
|
|
'''
|
|
== Comments And Links
|
|
(visible only on this page)
|
|
|
|
include::../comments-and-links.adoc[]
|
|
|
|
endif::env-github,rspecator-view[]
|