make in-line code blocks verbatim

rules/S100/abap/rule.adoc

@@ -2,7 +2,7 @@ include::../description.adoc[]
 
 == Noncompliant Code Example
 
-With default provided regular expression ``^([A-Z0-9_]*|[a-z0-9_]*)$``:
+With default provided regular expression ``++^([A-Z0-9_]*|[a-z0-9_]*)$++``:
 
 ----
 METHOD MyMethod

rules/S100/apex/rule.adoc

@@ -2,7 +2,7 @@ include::../description.adoc[]
 
 == Noncompliant Code Example
 
-With provided regular expression ``^[a-z][a-zA-Z0-9_]*$``:
+With provided regular expression ``++^[a-z][a-zA-Z0-9_]*$++``:
 
 ----
 public void DoSomething(){...}

rules/S100/cfamily/rule.adoc

@@ -2,7 +2,7 @@ include::../description.adoc[]
 
 == Noncompliant Code Example
 
-With default provided regular expression: ``^[a-z][a-zA-Z0-9]*$``:
+With default provided regular expression: ``++^[a-z][a-zA-Z0-9]*$++``:
 
 ----
 void DoSomething (void);

rules/S100/csharp/rule.adoc

@@ -1,4 +1,4 @@
-Shared naming conventions allow teams to collaborate efficiently. This rule checks whether or not method and property names are PascalCased. To reduce noise, two consecutive upper case characters are allowed unless they form the whole name. So, ``MyXMethod`` is compliant, but ``XM`` on its own is not.
+Shared naming conventions allow teams to collaborate efficiently. This rule checks whether or not method and property names are PascalCased. To reduce noise, two consecutive upper case characters are allowed unless they form the whole name. So, ``++MyXMethod++`` is compliant, but ``++XM++`` on its own is not.
 
 == Noncompliant Code Example
 
@@ -14,10 +14,10 @@ public int DoSomething() {...}
 
 == Exceptions
 
-* The rule ignores members in types that are marked with ``ComImportAttribute`` or ``InterfaceTypeAttribute``.
-* The rule ignores ``extern`` methods.
-* The rule allows for two-letter acronyms in which both letters are capitalized, as shown in the following identifier: ``ExecuteOnUIThread``.
-* Furthermore, when ``'_'`` character is found in a name, the camel casing is not enforced.
+* The rule ignores members in types that are marked with ``++ComImportAttribute++`` or ``++InterfaceTypeAttribute++``.
+* The rule ignores ``++extern++`` methods.
+* The rule allows for two-letter acronyms in which both letters are capitalized, as shown in the following identifier: ``++ExecuteOnUIThread++``.
+* Furthermore, when ``++'_'++`` character is found in a name, the camel casing is not enforced.
 
 ----
 void My_method(){...} // valid

rules/S100/go/rule.adoc

@@ -2,7 +2,7 @@ include::../description.adoc[]
 
 == Noncompliant Code Example
 
-With default provided regular expression: ``^(_|[a-zA-Z0-9]+)$``:
+With default provided regular expression: ``++^(_|[a-zA-Z0-9]+)$++``:
 
 ----
 func execute_all() {

rules/S100/java/rule.adoc

@@ -2,7 +2,7 @@ Shared naming conventions allow teams to collaborate efficiently. This rule chec
 
 == Noncompliant Code Example
 
-With default provided regular expression ``^[a-z][a-zA-Z0-9]*$``:
+With default provided regular expression ``++^[a-z][a-zA-Z0-9]*$++``:
 
 ----
 public int DoSomething(){...}

rules/S100/javascript/rule.adoc

@@ -2,7 +2,7 @@ include::../description.adoc[]
 
 == Noncompliant Code Example
 
-With the default regular expression ``^[a-z][a-zA-Z0-9]*$``:
+With the default regular expression ``++^[a-z][a-zA-Z0-9]*$++``:
 
 ----
 function DoSomething(){...}  // Noncompliant

rules/S100/php/rule.adoc

@@ -2,7 +2,7 @@ include::../description.adoc[]
 
 == Noncompliant Code Example
 
-With default provided regular expression: ``^[a-z][a-zA-Z0-9]*$``:
+With default provided regular expression: ``++^[a-z][a-zA-Z0-9]*$++``:
 
 ----
 function DoSomething(){...} 
@@ -16,7 +16,7 @@ function doSomething(){...}
 
 == Exceptions
 
-Methods with an ``@inheritdoc`` annotation, as well as magic methods (``__construct()``, ``__destruct()``, ``__call()``, ``__callStatic()``, ``__get()``, ``__set()``, ``__isset()``, ``__unset()``, ``__sleep()``, ``__wakeup()``, ``__toString()``, ``__invoke()``, ``__set\_state()``, ``__clone()``, ``__debugInfo()``) are ignored.
+Methods with an ``++@inheritdo{cpp}`` annotation, as well as magic methods (``++__construct()++``, ``++__destruct()++``, ``++__call()++``, ``++__callStatic()++``, ``++__get()++``, ``++__set()++``, ``++__isset()++``, ``++__unset()++``, ``++__sleep()++``, ``++__wakeup()++``, ``++__toString()++``, ``++__invoke()++``, ``++__set\_state()++``, ``++__clone()++``, ``++__debugInfo()++``) are ignored.
 
 ----
 function __construct(){...}

rules/S100/python/rule.adoc

@@ -2,7 +2,7 @@ Sharing some naming conventions is a key point to make it possible for a team to
 
 == Noncompliant Code Example
 
-With default provided regular expression: ``^[a-z_][a-z0-9_]*$``
+With default provided regular expression: ``++^[a-z_][a-z0-9_]*$++``
 
 ----
 class MyClass:

rules/S100/rpg/rule.adoc

@@ -2,7 +2,7 @@ Sharing some naming conventions is a key point to make it possible for a team to
 
 == Noncompliant Code Example
 
-With default provided regular expression ``^SR[a-zA-Z0-9]*$``:
+With default provided regular expression ``++^SR[a-zA-Z0-9]*$++``:
 
 ----
 C     XXXXX         BEGSR

rules/S1003/rule.adoc

@@ -53,5 +53,5 @@ The issue only happens if the using directive is at global scope or at namespace
 == See
 
 * MISRA {cpp}:2008, 7-3-6 - using-directives and using-declarations (excluding class scope or function scope using-declarations) shall not be used in header files.
-* https://github.com/isocpp/CppCoreGuidelines/blob/036324/CppCoreGuidelines.md#sf7-dont-write-using-namespace-at-global-scope-in-a-header-file[{cpp} Core Guidelines SF.7] - Don’t write ``using namespace`` at global scope in a header file
+* https://github.com/isocpp/CppCoreGuidelines/blob/036324/CppCoreGuidelines.md#sf7-dont-write-using-namespace-at-global-scope-in-a-header-file[{cpp} Core Guidelines SF.7] - Don’t write ``++using namespace++`` at global scope in a header file
 

rules/S1005/plsql/rule.adoc

@@ -1,4 +1,4 @@
-Procedures, unlike functions, do not return values. The ``RETURN`` statement therefore, when used within a procedure, is used to prematurely end the procedure. However, having multiple exit points (i.e. more than the ``END`` of the procedure itself), increases the complexity of the procedure and makes it harder to understand and debug.
+Procedures, unlike functions, do not return values. The ``++RETURN++`` statement therefore, when used within a procedure, is used to prematurely end the procedure. However, having multiple exit points (i.e. more than the ``++END++`` of the procedure itself), increases the complexity of the procedure and makes it harder to understand and debug.
 
 == Noncompliant Code Example
 

rules/S1009/rule.adoc

@@ -1,4 +1,4 @@
-The use of ``enum`` as a bit-field type is prohibited because ISO/IEC 14882:2003 does not explicitly define the underlying representation as ``signed`` or ``unsigned``. It is therefore not possible to determine the exact number of bits required to represent all values in the enumeration.
+The use of ``++enum++`` as a bit-field type is prohibited because ISO/IEC 14882:2003 does not explicitly define the underlying representation as ``++signed++`` or ``++unsigned++``. It is therefore not possible to determine the exact number of bits required to represent all values in the enumeration.
 
 
 == Noncompliant Code Example

rules/S101/abap/rule.adoc

@@ -2,7 +2,7 @@ include::../description.adoc[]
 
 == Noncompliant Code Example
 
-With the default provided regular expression ``^([A-Z0-9_]*|[a-z0-9_]*)$``:
+With the default provided regular expression ``++^([A-Z0-9_]*|[a-z0-9_]*)$++``:
 
 ----
 CLASS MyClass DEFINITION. 

rules/S101/apex/rule.adoc

@@ -2,7 +2,7 @@ include::../description.adoc[]
 
 == Noncompliant Code Example
 
-With default provided regular expression ``^[A-Z][a-zA-Z0-9_]*$``:
+With default provided regular expression ``++^[A-Z][a-zA-Z0-9_]*$++``:
 
 ----
 class myClass {}

rules/S101/cfamily/rule.adoc

@@ -3,7 +3,7 @@ This rule allows to check that all class names (along with Objective-C interface
 
 == Noncompliant Code Example
 
-With default provided regular expression ``^[A-Z][a-zA-Z0-9]*$``:
+With default provided regular expression ``++^[A-Z][a-zA-Z0-9]*$++``:
 
 ----
 // C++

rules/S101/csharp/rule.adoc

@@ -1,4 +1,4 @@
-Shared naming conventions allow teams to collaborate efficiently. This rule checks whether or not type names are using PascalCase. To reduce noise, two consecutive upper case characters are allowed unless they form the whole type name. So, ``MyXClass`` is compliant, but ``XC`` on its own is not.
+Shared naming conventions allow teams to collaborate efficiently. This rule checks whether or not type names are using PascalCase. To reduce noise, two consecutive upper case characters are allowed unless they form the whole type name. So, ``++MyXClass++`` is compliant, but ``++X{cpp}`` on its own is not.
 
 == Noncompliant Code Example
 
@@ -16,9 +16,9 @@ class SomeName42 {...}
 
 == Exceptions
 
-* The rule ignores types that are marked with ``ComImportAttribute`` or ``InterfaceTypeAttribute``. 
-* The rule allows for two-letter acronyms in which both letters are capitalized, as shown in the following identifier: ``IOStream``
-* The rule allows having ``'_'`` characters in class names inside test projects.
+* The rule ignores types that are marked with ``++ComImportAttribute++`` or ``++InterfaceTypeAttribute++``. 
+* The rule allows for two-letter acronyms in which both letters are capitalized, as shown in the following identifier: ``++IOStream++``
+* The rule allows having ``++'_'++`` characters in class names inside test projects.
 
 ----
 class Some_Name___42 {...} // valid in test

rules/S101/flex/rule.adoc

@@ -2,7 +2,7 @@ include::../description.adoc[]
 
 == Noncompliant Code Example
 
-With default provided regular expression ``^[A-Z][a-zA-Z0-9]*$``:
+With default provided regular expression ``++^[A-Z][a-zA-Z0-9]*$++``:
 
 ----
 public class myClass {...}

rules/S101/go/rule.adoc

@@ -6,7 +6,7 @@ Note that the casing of the first character determines if the type is exported o
 
 == Noncompliant Code Example
 
-With default provided regular expression ``^[a-zA-Z][a-zA-Z0-9]*$``:
+With default provided regular expression ``++^[a-zA-Z][a-zA-Z0-9]*$++``:
 
 ----
 type my_struct struct {...}

rules/S101/noncompliant.adoc

@@ -1,6 +1,6 @@
 == Noncompliant Code Example
 
-With default provided regular expression ``^[A-Z][a-zA-Z0-9]*$``:
+With default provided regular expression ``++^[A-Z][a-zA-Z0-9]*$++``:
 
 ----
 class my_class {...}

rules/S101/python/rule.adoc

@@ -4,7 +4,7 @@ The default regular expression is based on PEP-8 standard. It allows "CapWords"
 
 == Noncompliant Code Example
 
-With default provided regular expression ``^_?([A-Z_][a-zA-Z0-9]\*|[a-z_][a-z0-9_]\*)$``:
+With default provided regular expression ``++^_?([A-Z_][a-zA-Z0-9]\*|[a-z_][a-z0-9_]\*)$++``:
 
 ----
 class myClass:  # Noncompliant

rules/S101/ruby/rule.adoc

@@ -2,7 +2,7 @@ include::../description.adoc[]
 
 == Noncompliant Code Example
 
-With default provided regular expression ``^[A-Z][a-zA-Z0-9]*$``:
+With default provided regular expression ``++^[A-Z][a-zA-Z0-9]*$++``:
 
 ----
 class my_class

rules/S101/vbnet/rule.adoc

@@ -8,7 +8,7 @@ The default configuration is the one recommended by Microsoft:
 
 == Noncompliant Code Example
 
-With the default regular expression ``^([A-Z]{1,3}[a-z0-9]+)*([A-Z]{2})?$``:
+With the default regular expression ``++^([A-Z]{1,3}[a-z0-9]+)*([A-Z]{2})?$++``:
 
 ----
 Class foo ' Noncompliant

rules/S1012/rule.adoc

@@ -1,4 +1,4 @@
-The use of ``virtual`` base classes can introduce a number of undefined and potentially confusing behaviours. Therefore, a base class shall only be declared ``virtual`` if that base class is to be used as a common base class in a diamond hierarchy.
+The use of ``++virtual++`` base classes can introduce a number of undefined and potentially confusing behaviours. Therefore, a base class shall only be declared ``++virtual++`` if that base class is to be used as a common base class in a diamond hierarchy.
 
 
 == Noncompliant Code Example

rules/S1013/rule.adoc

@@ -1,4 +1,4 @@
-If a base class is both ``virtual`` and non-virtual in a multiple inheritance hierarchy then there will be at least two copies of the base class sub-object in the derived object. This may not be consistent with developer expectations.
+If a base class is both ``++virtual++`` and non-virtual in a multiple inheritance hierarchy then there will be at least two copies of the base class sub-object in the derived object. This may not be consistent with developer expectations.
 
 
 == Noncompliant Code Example

rules/S1016/rule.adoc

@@ -1,4 +1,4 @@
-For code compliant with {cpp}98 or {cpp}03 standards, declaring overriding virtual functions with the ``virtual`` keyword removes the need to check the base class to determine whether a function is virtual.
+For code compliant with {cpp}98 or {cpp}03 standards, declaring overriding virtual functions with the ``++virtual++`` keyword removes the need to check the base class to determine whether a function is virtual.
 
 
 == Noncompliant Code Example

rules/S1017/rule.adoc

@@ -1,6 +1,6 @@
-A ``virtual`` function has an implementation that _may_ be replaced in a child class. A pure ``virtual`` has no implementation, and _must_ be implemented in child classes.
+A ``++virtual++`` function has an implementation that _may_ be replaced in a child class. A pure ``++virtual++`` has no implementation, and _must_ be implemented in child classes.
 
-Hiding a base class implementation with a "pure implementation" (``=0``) is sure to confuse extenders, who may not be aware of the base class' implementation. Instead, they'll see there's no implementation in the class they're extending and assume that none exists. When that base class implementation contains crucial functionality such as freeing resources, this could cause future users of the class to introduce bugs.
+Hiding a base class implementation with a "pure implementation" (``++=0++``) is sure to confuse extenders, who may not be aware of the base class' implementation. Instead, they'll see there's no implementation in the class they're extending and assume that none exists. When that base class implementation contains crucial functionality such as freeing resources, this could cause future users of the class to introduce bugs.
 
 This rule raises an issue if a pure virtual function overrides a virtual function that is not pure.
 

rules/S1019/rule.adoc

@@ -1,8 +1,8 @@
 During construction and destruction of an object, its final type may be different from that of the completely constructed object. The result of using an object’s dynamic type in a constructor or destructor may not be consistent with developer expectations.
 The dynamic type of an object is used in the following constructs:
 
-* ``typeid`` on a class with a virtual function or a virtual function in a base class.
-* ``dynamic_cast``
+* ``++typeid++`` on a class with a virtual function or a virtual function in a base class.
+* ``++dynamic_cast++``
 * A virtual call to a virtual function.
 
 This rule also prohibits a call being made to a pure virtual function from within a constructor or destructor. Such calls lead to undefined behaviour.

rules/S1027/rule.adoc

@@ -1,4 +1,4 @@
-Using a qualified-id or prefixing the identifier with ``this->`` ensures that the entity chosen is consistent with developer expectations.
+Using a qualified-id or prefixing the identifier with ``++this->++`` ensures that the entity chosen is consistent with developer expectations.
 
 
 == Noncompliant Code Example

rules/S1035/rule.adoc

@@ -1,4 +1,4 @@
-If a pointer to an object is used as an exception, the code that will catch the exception may or may not have to delete the pointed-to object. This is even more complex in the exception case than in classical manual memory management, because of the distance between the ``throw`` statements and the matching ``catch``. 
+If a pointer to an object is used as an exception, the code that will catch the exception may or may not have to delete the pointed-to object. This is even more complex in the exception case than in classical manual memory management, because of the distance between the ``++throw++`` statements and the matching ``++catch++``. 
 
 Throwing by value is just simpler and less error prone.
 

rules/S1036/rule.adoc

@@ -1,8 +1,8 @@
-Having a ``switch`` and its cases wholly encompassed by a control structure such as a ``try``, ``@try``, ``catch``, ``@catch``, or a loop is perfectly acceptable. (``try`` and ``catch`` are used hereafter to refer to both variants.) It is also acceptable to have a ``goto`` and its target label wholly encompassed in a control structure. 
+Having a ``++switch++`` and its cases wholly encompassed by a control structure such as a ``++try++``, ``++@try++``, ``++catch++``, ``++@catch++``, or a loop is perfectly acceptable. (``++try++`` and ``++catch++`` are used hereafter to refer to both variants.) It is also acceptable to have a ``++goto++`` and its target label wholly encompassed in a control structure. 
 
-What is not acceptable is using a ``goto`` or ``case`` to suddenly jump into the body of a ``try``, ``catch``, Objective-C ``@finally``, or loop structure. Tangling labels or ``switch`` blocks with other control structures results in code that is difficult, if not impossible to understand. More importantly, when it compiles (some of these constructs won't compile under ISO-conformant compilers), it can lead to unexpected results. Therefore this usage should be strictly avoided.
+What is not acceptable is using a ``++goto++`` or ``++case++`` to suddenly jump into the body of a ``++try++``, ``++catch++``, Objective-C ``++@finally++``, or loop structure. Tangling labels or ``++switch++`` blocks with other control structures results in code that is difficult, if not impossible to understand. More importantly, when it compiles (some of these constructs won't compile under ISO-conformant compilers), it can lead to unexpected results. Therefore this usage should be strictly avoided.
 
-This {cpp} code sample, which is also applicable to Objective-C if ``try`` and ``catch`` are converted to ``@try`` and ``@catch``, demonstrates jumping into a ``switch`` and into a ``try`` and ``catch`` :
+This {cpp} code sample, which is also applicable to Objective-C if ``++try++`` and ``++catch++`` are converted to ``++@try++`` and ``++@catch++``, demonstrates jumping into a ``++switch++`` and into a ``++try++`` and ``++catch++`` :
 
 
 == Noncompliant Code Example

rules/S1039/cfamily/rule.adoc

@@ -6,4 +6,4 @@ include::../compliant.adoc[]
 
 == See
 
-* MISRA {cpp}:2008, 15-1-3 - An empty throw (``throw;``) shall only be used in the compound-statement of a catch handler.
+* MISRA {cpp}:2008, 15-1-3 - An empty throw (``++throw;++``) shall only be used in the compound-statement of a catch handler.

rules/S1039/description.adoc

@@ -1,3 +1,3 @@
-An empty ``throw`` re-throws the temporary object that represents the exception being processed. It is intended to allow partially handling an exception at some level in the call stack (for instance, logging an issue) but then forwarding it to a higher level where it will be fully handled.
+An empty ``++throw++`` re-throws the temporary object that represents the exception being processed. It is intended to allow partially handling an exception at some level in the call stack (for instance, logging an issue) but then forwarding it to a higher level where it will be fully handled.
 
-However, syntactically, there is nothing to prevent ``throw;`` being used outside a catch handler, where there might be no exception object to re-throw. In such a case, the program would call ``std::terminate``, which is probably not the expected behavior.
+However, syntactically, there is nothing to prevent ``++throw;++`` being used outside a catch handler, where there might be no exception object to re-throw. In such a case, the program would call ``++std::terminate++``, which is probably not the expected behavior.

rules/S1040/rule.adoc

@@ -1,4 +1,4 @@
-Throwing an exception during startup or shutdown results in an implementation-defined termination of the program. This is because there is no where to put ``try``/``catch`` blocks to catch exceptions thrown in the startup phase, when static objects are being constructed, or during the shutdown phase, when those static objects are being destroyed.
+Throwing an exception during startup or shutdown results in an implementation-defined termination of the program. This is because there is no where to put ``++try++``/``++catch++`` blocks to catch exceptions thrown in the startup phase, when static objects are being constructed, or during the shutdown phase, when those static objects are being destroyed.
 
 Therefore exceptions should not be thrown during the construction or destruction of static objects.
 

rules/S1041/compliant.adoc

@@ -1,6 +1,6 @@
 == Compliant Solution
 
-For the majority of programs this will mean ``main`` should look like:
+For the majority of programs this will mean ``++main++`` should look like:
 
 ----
 int32_t main( )

rules/S1041/plsql/rule.adoc

@@ -1,4 +1,4 @@
-Ensure that every possible exception is caught by using a ``WHEN OTHERS`` clause.
+Ensure that every possible exception is caught by using a ``++WHEN OTHERS++`` clause.
 
 == Noncompliant Code Example
 

rules/S1045/description.adoc

@@ -1 +1 @@
-Exceptions handlers (``catch ()``) are evaluated in the order they are written. Once a match is found, the evaluation stops. If there is a handler for a base class followed by a handler for class derived from that base class, the second handler will never trigger: The handler for the base class will match the derived class, and will be the only executed handler. The derived class handler is dead code.
+Exceptions handlers (``++catch ()++``) are evaluated in the order they are written. Once a match is found, the evaluation stops. If there is a handler for a base class followed by a handler for class derived from that base class, the second handler will never trigger: The handler for the base class will match the derived class, and will be the only executed handler. The derived class handler is dead code.

rules/S1045/php/rule.adoc

@@ -1,11 +1,11 @@
-Exceptions handlers (``catch``) are evaluated in the order they are written. Once a match is found, the evaluation stops.
+Exceptions handlers (``++catch++``) are evaluated in the order they are written. Once a match is found, the evaluation stops.
 
-In some contexts a ``catch`` block is dead code as it will never catch any exception:
+In some contexts a ``++catch++`` block is dead code as it will never catch any exception:
 
 * If there is a handler for a base class followed by a handler for class derived from that base class, the second handler will never trigger: the handler for the base class will match the derived class, and will be the only executed handler.
-* When multiple ``catch`` blocks try to catch the same exception class, only the first one will be executed.
+* When multiple ``++catch++`` blocks try to catch the same exception class, only the first one will be executed.
 
-This rule raises an issue when a ``catch`` block catches every exception before a later ``catch`` block could catch it.
+This rule raises an issue when a ``++catch++`` block catches every exception before a later ``++catch++`` block could catch it.
 
 == Noncompliant Code Example
 

rules/S1045/python/rule.adoc

@@ -1,12 +1,12 @@
-Exceptions handlers (``except:``) are evaluated in the order they are written. Once a match is found, the evaluation stops.
+Exceptions handlers (``++except:++``) are evaluated in the order they are written. Once a match is found, the evaluation stops.
 
 In some contexts an except block is dead code as it will never catch any exception:
 
 * If there is a handler for a base class followed by a handler for class derived from that base class, the second handler will never trigger: The handler for the base class will match the derived class, and will be the only executed handler.
-* When multiple ``except`` statements try to catch the same exception class, only the first one will be executed.
-* In python 3, ``BaseException`` is the parent of every exception class. When ``BaseException`` is caught and the same try-except block has a bare ``except:`` statement, i.e. an ``except`` with no expression, the bare except will never catch anything.
+* When multiple ``++except++`` statements try to catch the same exception class, only the first one will be executed.
+* In python 3, ``++BaseException++`` is the parent of every exception class. When ``++BaseException++`` is caught and the same try-except block has a bare ``++except:++`` statement, i.e. an ``++except++`` with no expression, the bare except will never catch anything.
 
-This rule raises an issue when an ``except`` block catches every exception before a later ``except`` block could catch it.
+This rule raises an issue when an ``++except++`` block catches every exception before a later ``++except++`` block could catch it.
 
 == Noncompliant Code Example
 
@@ -62,4 +62,4 @@ def foo():
 
 == See
 
-* Python Documentation - https://docs.python.org/3/reference/compound_stmts.html#the-try-statement[The ``try`` statement]
+* Python Documentation - https://docs.python.org/3/reference/compound_stmts.html#the-try-statement[The ``++try++`` statement]

rules/S1046/description.adoc

@@ -1,3 +1,3 @@
-The catch-all handler should come last in a chain of ``catch`` or ``@catch`` statements because it catches everything, and any more-specific ``catch``/``@catch`` that comes after it will never be used, even when the relevant condition occurs. 
+The catch-all handler should come last in a chain of ``++catch++`` or ``++@catch++`` statements because it catches everything, and any more-specific ``++catch++``/``++@catch++`` that comes after it will never be used, even when the relevant condition occurs. 
 
-This {cpp} code sample is very similar to the Objective-C equivalent with ``@try`` and ``@catch``.
+This {cpp} code sample is very similar to the Objective-C equivalent with ``++@try++`` and ``++@catch++``.

rules/S1050/rule.adoc

@@ -1,4 +1,4 @@
-It is implementation-defined whether the call stack is unwound before ``terminate()`` is called, so the destructors of any automatic objects may or may not be executed.
+It is implementation-defined whether the call stack is unwound before ``++terminate()++`` is called, so the destructors of any automatic objects may or may not be executed.
 
 
 == See

rules/S1052/rule.adoc

@@ -1,4 +1,4 @@
-Various aspects of ``ctime`` are implementation-defined or unspecified, such as the formats of times. 
+Various aspects of ``++ctime++`` are implementation-defined or unspecified, such as the formats of times. 
 
 
 == Noncompliant Code Example

rules/S1053/rule.adoc

@@ -1,6 +1,6 @@
-Used correctly, the functions from the ``<cstring>`` library are safe and reliable. Unfortunately, they are easily misused, and can read or write beyond the end of defined buffer, resulting in undefined behavior. 
+Used correctly, the functions from the ``++<cstring>++`` library are safe and reliable. Unfortunately, they are easily misused, and can read or write beyond the end of defined buffer, resulting in undefined behavior. 
 
-Therefore this rule flags all uses of the following methods, which should be avoided, in favor of functions from {cpp}'s new "safe string" library, ``<string>``: ``strcpy``, ``strcmp``, ``strcat``, ``strchr``, ``strspn``, ``strcspn``, ``strpbrk``, ``strrchr``, ``strstr``, ``strtok``, and ``strlen``.
+Therefore this rule flags all uses of the following methods, which should be avoided, in favor of functions from {cpp}'s new "safe string" library, ``++<string>++``: ``++strcpy++``, ``++strcmp++``, ``++strcat++``, ``++strchr++``, ``++strspn++``, ``++strcspn++``, ``++strpbrk++``, ``++strrchr++``, ``++strstr++``, ``++strtok++``, and ``++strlen++``.
 
 
 == Noncompliant Code Example

rules/S1055/rule.adoc

@@ -1,4 +1,4 @@
-This includes file and I/O functions ``fgetpos``, ``fopen``, ``ftell``, ``gets``, ``perror``, ``remove``, ``rename``, etc.
+This includes file and I/O functions ``++fgetpos++``, ``++fopen++``, ``++ftell++``, ``++gets++``, ``++perror++``, ``++remove++``, ``++rename++``, etc.
 
 Streams and file I/O have a large number of unspecified, undefined and implementation-defined behaviors associated with them.
 

rules/S1056/rule.adoc

@@ -1,8 +1,8 @@
 Compound triggers were introduced to ease the implementation of multiple triggers which need to work in cooperation.
 
-Typically, a ``FOR EACH ROW`` trigger accumulates facts, and an ``AFTER STATEMENT`` trigger performs the actual changes.
+Typically, a ``++FOR EACH ROW++`` trigger accumulates facts, and an ``++AFTER STATEMENT++`` trigger performs the actual changes.
 
-The compound trigger can hold a state common to all the triggers it defines, thereby removing the need to use package variables. This approach is sometimes the only possible one, as when avoiding a mutating table ``ORA-04091`` error, or it can be used to get better performance.
+The compound trigger can hold a state common to all the triggers it defines, thereby removing the need to use package variables. This approach is sometimes the only possible one, as when avoiding a mutating table ``++ORA-04091++`` error, or it can be used to get better performance.
 
 However, there is no point in defining a compound trigger which contains only a single trigger, since there is no state to be shared. In such cases, a simple trigger should be used instead.
 

rules/S1057/rule.adoc

@@ -1,4 +1,4 @@
-Some Oracle packages contain powerful SYS-owned functions that can be used to perform malicious operations. For instance, ``DBMS_SYS_SQL.PARSE_AS_USER`` can be used to execute a statement as another user.
+Some Oracle packages contain powerful SYS-owned functions that can be used to perform malicious operations. For instance, ``++DBMS_SYS_SQL.PARSE_AS_USER++`` can be used to execute a statement as another user.
 
 Most programs do not need those functions and this rule helps identify them in order to prevent security risks.
 

rules/S1058/rule.adoc

@@ -1,8 +1,8 @@
 Pipelined functions offers the ability to create programmatically generated tables.
 One of the benefits of such functions is that they reduce memory consumption as results are not all kept in memory before being returned.
-Instead of relying on ``RETURN``, ``PIPE ROW`` must be used to return the results, one row at a time.
+Instead of relying on ``++RETURN++``, ``++PIPE ROW++`` must be used to return the results, one row at a time.
 
-Trying to return an expression from a pipelined function raises ``PLS-00633: RETURN statement in a pipelined function cannot contain an expression``
+Trying to return an expression from a pipelined function raises ``++PLS-00633: RETURN statement in a pipelined function cannot contain an expression++``
 
 
 == Noncompliant Code Example

rules/S1059/rule.adoc

@@ -1,4 +1,4 @@
-Since Oracle 10g, ``DBMS_UTILITY.FORMAT_ERROR_BACKTRACE`` is available to get an exception's stack trace, i.e. files and lines that lead up to the exception. When combined with ``DBMS_UTILITY.FORMAT_ERROR_STACK``, which contains the exception error code and message, developers are able quickly identify defects.
+Since Oracle 10g, ``++DBMS_UTILITY.FORMAT_ERROR_BACKTRACE++`` is available to get an exception's stack trace, i.e. files and lines that lead up to the exception. When combined with ``++DBMS_UTILITY.FORMAT_ERROR_STACK++``, which contains the exception error code and message, developers are able quickly identify defects.
 
 This rule verifies that whenever either is used in an exception handler, the other is used as well.
 

rules/S106/csharp/rule.adoc

@@ -16,7 +16,7 @@ private void DoSomething()
 The following are ignored by this rule:
 
 * Console Applications
-* Calls in methods decorated with ``[Conditional ("DEBUG")]``
-* Calls included in DEBUG preprocessor branches (``#if DEBUG``)
+* Calls in methods decorated with ``++[Conditional ("DEBUG")]++``
+* Calls included in DEBUG preprocessor branches (``++#if DEBUG++``)
 
 include::../see.adoc[]

rules/S1062/rule.adoc

@@ -1,7 +1,7 @@
 According to the Java Language Specification:
 
 ____
-It is permitted, but discouraged as a matter of style, to redundantly specify the ``public`` and/or ``abstract`` modifier for a method declared in an interface.
+It is permitted, but discouraged as a matter of style, to redundantly specify the ``++publi{cpp}`` and/or ``++abstract++`` modifier for a method declared in an interface.
 ____
 
 

rules/S1066/cobol/rule.adoc

@@ -1,4 +1,4 @@
-Merging collapsible ``IF`` statements increases the code's readability.
+Merging collapsible ``++IF++`` statements increases the code's readability.
 
 == Noncompliant Code Example
 

rules/S1066/description.adoc

@@ -1 +1 @@
-Merging collapsible ``if`` statements increases the code's readability.
+Merging collapsible ``++if++`` statements increases the code's readability.

rules/S1067/abap/rule.adoc

@@ -1,4 +1,4 @@
-The complexity of an expression is defined by the number of ``AND``, ``OR``, ``XOR`` and ``EQUIV`` operators it contains.
+The complexity of an expression is defined by the number of ``++AND++``, ``++OR++``, ``++XOR++`` and ``++EQUIV++`` operators it contains.
 A single expression's complexity should not become too high to keep the code readable.
 
 == Noncompliant Code Example

rules/S1067/apex/rule.adoc

@@ -1,4 +1,4 @@
-The complexity of an expression is defined by the number of ``&&`` and ``||`` operators it contains.
+The complexity of an expression is defined by the number of ``++&&++`` and ``++||++`` operators it contains.
 A single expression's complexity should not become too high to keep the code readable.
 
 == Noncompliant Code Example

rules/S1067/description.adoc

@@ -1,2 +1,2 @@
-The complexity of an expression is defined by the number of ``&&``, ``||`` and ``condition ? ifTrue : ifFalse`` operators it contains.
+The complexity of an expression is defined by the number of ``++&&++``, ``++||++`` and ``++condition ? ifTrue : ifFalse++`` operators it contains.
 A single expression's complexity should not become too high to keep the code readable.

rules/S1067/java/rule.adoc

@@ -16,4 +16,4 @@ if ( (myFirstCondition() || mySecondCondition()) && myLastCondition()) { ... }
 
 == Exceptions
 
-No issue is reported inside ``equals`` methods, because it is common to compare all the fields of a class for equality inside this kind of method.
+No issue is reported inside ``++equals++`` methods, because it is common to compare all the fields of a class for equality inside this kind of method.

rules/S1067/rpg/rule.adoc

@@ -1,4 +1,4 @@
-The complexity of an expression is defined by the number of ``AND``, ``OR``.
+The complexity of an expression is defined by the number of ``++AND++``, ``++OR++``.
 A single expression's complexity should not become too high to keep the code readable.
 
 == Noncompliant Code Example

rules/S1067/scala/rule.adoc

@@ -1,4 +1,4 @@
-The complexity of an expression is defined by the number of ``&&`` and ``||`` operators it contains.
+The complexity of an expression is defined by the number of ``++&&++`` and ``++||++`` operators it contains.
 A single expression's complexity should not become too high to keep the code readable.
 
 == Noncompliant Code Example

rules/S1067/tsql/rule.adoc

@@ -1,4 +1,4 @@
-The complexity of an expression is defined by the number of ``AND`` and ``OR`` operators it contains.
+The complexity of an expression is defined by the number of ``++AND++`` and ``++OR++`` operators it contains.
 A single expression's complexity should not become too high to keep the code readable.
 
 == Noncompliant Code Example

rules/S1067/vb6/rule.adoc

@@ -1,4 +1,4 @@
-The difficulty of understanding an expression increases for each of the ``And``, ``Or`` and ``Xor`` operators it contains.
+The difficulty of understanding an expression increases for each of the ``++And++``, ``++Or++`` and ``++Xor++`` operators it contains.
 A single expression's complexity should not become too high to keep the code readable.
 
 == Noncompliant Code Example

rules/S1068/description.adoc

@@ -1 +1 @@
-If a ``private`` field is declared but not used in the program, it can be considered dead code and should therefore be removed. This will improve maintainability because developers will not wonder what the variable is used for.
+If a ``++private++`` field is declared but not used in the program, it can be considered dead code and should therefore be removed. This will improve maintainability because developers will not wonder what the variable is used for.

rules/S1068/java/rule.adoc

@@ -1,6 +1,6 @@
-If a ``private`` field is declared but not used in the program, it can be considered dead code and should therefore be removed. This will improve maintainability because developers will not wonder what the variable is used for.
+If a ``++private++`` field is declared but not used in the program, it can be considered dead code and should therefore be removed. This will improve maintainability because developers will not wonder what the variable is used for.
 
-Note that this rule does not take reflection into account, which means that issues will be raised on ``private`` fields that are only accessed using the reflection API.
+Note that this rule does not take reflection into account, which means that issues will be raised on ``++private++`` fields that are only accessed using the reflection API.
 
 == Noncompliant Code Example
 
@@ -27,8 +27,8 @@ public class MyClass {
 
 == Exceptions
 
-The Java serialization runtime associates with each serializable class a version number, called ``serialVersionUID``, which is used during deserialization to verify that the sender and receiver of a serialized object have loaded classes for that object that are compatible with respect to serialization.
-A serializable class can declare its own ``serialVersionUID`` explicitly by declaring a field named ``serialVersionUID`` that must be static, final, and of type long. By definition those ``serialVersionUID`` fields should not be reported by this rule:
+The Java serialization runtime associates with each serializable class a version number, called ``++serialVersionUID++``, which is used during deserialization to verify that the sender and receiver of a serialized object have loaded classes for that object that are compatible with respect to serialization.
+A serializable class can declare its own ``++serialVersionUID++`` explicitly by declaring a field named ``++serialVersionUID++`` that must be static, final, and of type long. By definition those ``++serialVersionUID++`` fields should not be reported by this rule:
 
 ----
 public class MyClass implements java.io.Serializable {

rules/S107/java/rule.adoc

@@ -22,10 +22,10 @@ public void doSomething(int param1, int param2, int param3, String param4) {
 
 Methods annotated with :
 
-* Spring's ``@RequestMapping`` (and related shortcut annotations, like ``@GetRequest``)
-* JAX-RS API annotations (like ``@javax.ws.rs.GET``)
-* Bean constructor injection with ``@org.springframework.beans.factory.annotation.Autowired``
-* CDI constructor injection with ``@javax.inject.Inject``
-* ``@com.fasterxml.jackson.annotation.JsonCreator``
+* Spring's ``++@RequestMapping++`` (and related shortcut annotations, like ``++@GetRequest++``)
+* JAX-RS API annotations (like ``++@javax.ws.rs.GET++``)
+* Bean constructor injection with ``++@org.springframework.beans.factory.annotation.Autowired++``
+* CDI constructor injection with ``++@javax.inject.Inject++``
+* ``++@com.fasterxml.jackson.annotation.JsonCreator++``
 
 may have a lot of parameters, encapsulation being possible. Such methods are therefore ignored.

rules/S107/kotlin/rule.adoc

@@ -20,4 +20,4 @@ fun foo(p1: String, p2: String, p3: String, p4: String) {
 
 == Exceptions
 
-Methods annotated with Spring's ``@RequestMapping`` (and related shortcut annotations, like ``@GetRequest``) or ``@JsonCreator`` may have a lot of parameters, encapsulation being possible. Such methods are therefore ignored.
+Methods annotated with Spring's ``++@RequestMapping++`` (and related shortcut annotations, like ``++@GetRequest++``) or ``++@JsonCreator++`` may have a lot of parameters, encapsulation being possible. Such methods are therefore ignored.

rules/S107/python/rule.adoc

@@ -18,4 +18,4 @@ def do_something(param1, param2, param3, param4):
 
 == Exceptions
 
-The first argument of non-static methods, i.e. ``self`` or ``cls``, is not counted as it is mandatory and it is passed automatically.
+The first argument of non-static methods, i.e. ``++self++`` or ``++cls++``, is not counted as it is mandatory and it is passed automatically.

rules/S1070/rule.adoc

@@ -1,4 +1,4 @@
-The ``result_cache`` Oracle hint can vastly improve performance, but it comes at the cost of extra memory consumption, so one should double-check that the gain in performance is significant, and avoid overusing this feature in general.
+The ``++result_cache++`` Oracle hint can vastly improve performance, but it comes at the cost of extra memory consumption, so one should double-check that the gain in performance is significant, and avoid overusing this feature in general.
 
 
 == Noncompliant Code Example

rules/S1071/rule.adoc

@@ -1,4 +1,4 @@
-Since Oracle 11.2, ``RELIES_ON`` has been deprecated because the dependencies of result cache-enabled functions are automatically computed.
+Since Oracle 11.2, ``++RELIES_ON++`` has been deprecated because the dependencies of result cache-enabled functions are automatically computed.
 
 
 == Noncompliant Code Example

rules/S1074/rule.adoc

@@ -1,4 +1,4 @@
-When the ``FORALL`` statement is used without the ``SAVE EXCEPTIONS`` clause and an exception is raised by a DML query, the whole operation is rolled back and the exception goes unhandled. Instead of relying on this default behavior, it is better to always use the ``SAVE EXCEPTIONS`` clause and explicitly handle exceptions in a ``ORA-24381`` handler.
+When the ``++FORALL++`` statement is used without the ``++SAVE EXCEPTIONS++`` clause and an exception is raised by a DML query, the whole operation is rolled back and the exception goes unhandled. Instead of relying on this default behavior, it is better to always use the ``++SAVE EXCEPTIONS++`` clause and explicitly handle exceptions in a ``++ORA-24381++`` handler.
 
 
 == Noncompliant Code Example

rules/S1075/csharp/rule.adoc

@@ -8,8 +8,8 @@ This rule raises an issue when URI's or path delimiters are hardcoded.
 
 This rule does not raise an issue when an ASP.NET virtual path is passed as an argument to one of the following:
 
-* methods: ``System.Web.HttpServerUtilityBase.MapPath()``, ``System.Web.HttpRequestBase.MapPath()``, ``System.Web.HttpResponseBase.ApplyAppPathModifier()``, ``System.Web.Mvc.UrlHelper.Content()``
-* all methods of: ``System.Web.VirtualPathUtility``
-* constructors of: ``Microsoft.AspNetCore.Mvc.VirtualFileResult``, ``Microsoft.AspNetCore.Routing.VirtualPathData``
+* methods: ``++System.Web.HttpServerUtilityBase.MapPath()++``, ``++System.Web.HttpRequestBase.MapPath()++``, ``++System.Web.HttpResponseBase.ApplyAppPathModifier()++``, ``++System.Web.Mvc.UrlHelper.Content()++``
+* all methods of: ``++System.Web.VirtualPathUtility++``
+* constructors of: ``++Microsoft.AspNetCore.Mvc.VirtualFileResult++``, ``++Microsoft.AspNetCore.Routing.VirtualPathData++``
 
 include::../see.adoc[]

rules/S1077/rule.adoc

@@ -1,4 +1,4 @@
-The ``alt`` attribute provides a textual alternative to an image.
+The ``++alt++`` attribute provides a textual alternative to an image.
 It is used whenever the actual image cannot be rendered.
 Common reasons for that include:
 
@@ -6,12 +6,12 @@ Common reasons for that include:
 * Visually impaired users using a screen reader software
 * Images loading is disabled, to reduce data consumption on mobile phones
 
-It is also very important to not set an ``alt`` attribute to a non-informative value. For example ``<img ... alt="logo">`` is useless as it doesn't give any information to the user. In this case, as for any other decorative image, it is better to use a CSS background image instead of an ``<img>`` tag. If using CSS background-image is not possible, an empty ``alt=""`` is tolerated. See Exceptions bellow.
+It is also very important to not set an ``++alt++`` attribute to a non-informative value. For example ``++<img ... alt="logo">++`` is useless as it doesn't give any information to the user. In this case, as for any other decorative image, it is better to use a CSS background image instead of an ``++<img>++`` tag. If using CSS background-image is not possible, an empty ``++alt=""++`` is tolerated. See Exceptions bellow.
 
 This rule raises an issue when
 
-* an ``<input type="image">`` tag or an ``<area>`` tag have no ``alt`` attribute or their ``alt`` attribute has an empty string value.
-* an ``<img>`` tag has no ``alt`` attribute.
+* an ``++<input type="image">++`` tag or an ``++<area>++`` tag have no ``++alt++`` attribute or their ``++alt++`` attribute has an empty string value.
+* an ``++<img>++`` tag has no ``++alt++`` attribute.
 
 
 == Noncompliant Code Example
@@ -51,16 +51,16 @@ This rule raises an issue when
 
 == Exceptions
 
-``<img>`` tags with empty string ``alt=""`` attributes won't raise any issue. However this technic should be used in two cases only:
+``++<img>++`` tags with empty string ``++alt=""++`` attributes won't raise any issue. However this technic should be used in two cases only:
 
-When the image is decorative and it is not possible to use a CSS background image. For example, when the decorative ``<img>`` is generated via javascript with a source image coming from a database, it is better to use an ``<img alt="">`` tag rather than generate CSS code.
+When the image is decorative and it is not possible to use a CSS background image. For example, when the decorative ``++<img>++`` is generated via javascript with a source image coming from a database, it is better to use an ``++<img alt="">++`` tag rather than generate CSS code.
 
 ----
 <li *ngFor="let image of images">
     <img [src]="image" alt="">
 </li>
 ----
-When the image is not decorative but it's ``alt`` text would repeat a nearby text. For example, images contained in links should not duplicate the link's text in their ``alt`` attribute, as it would make the screen reader repeat the text twice.
+When the image is not decorative but it's ``++alt++`` text would repeat a nearby text. For example, images contained in links should not duplicate the link's text in their ``++alt++`` attribute, as it would make the screen reader repeat the text twice.
 
 ----
 <a href="flowers.html">

rules/S1079/rule.adoc

@@ -1,9 +1,9 @@
-The ``%s`` placeholder is used to read a word into a string.
+The ``++%s++`` placeholder is used to read a word into a string.
 By default, there is no restriction on the length of that word, and the developer is required to pass a sufficiently large buffer for storing it.
 No matter how large the buffer is, there will always be a longer word.
-Therefore, programs relying on ``%s`` are vulnerable to buffer overflows.
+Therefore, programs relying on ``++%s++`` are vulnerable to buffer overflows.
 
-A field width specifier can be used together with the ``%s`` placeholder to limit the number of bytes which will by written to the buffer.
+A field width specifier can be used together with the ``++%s++`` placeholder to limit the number of bytes which will by written to the buffer.
 Note that an additional byte is required to store the null terminator.
 
 

rules/S108/go/rule.adoc

@@ -24,4 +24,4 @@ func compute(a int, b int) {
 
 == Exceptions
 
-When a block contains a comment, this block is not considered to be empty. ``for`` without ``init`` and ``post`` statements with empty blocks are ignored as well.
+When a block contains a comment, this block is not considered to be empty. ``++for++`` without ``++init++`` and ``++post++`` statements with empty blocks are ignored as well.

rules/S108/java/rule.adoc

@@ -4,4 +4,4 @@ include::../noncompliant.adoc[]
 
 == Exceptions
 
-When a block contains a comment, this block is not considered to be empty unless it is a ``synchronized`` block. ``synchronized`` blocks are still considered empty even with comments because they can still affect program flow.
+When a block contains a comment, this block is not considered to be empty unless it is a ``++synchronized++`` block. ``++synchronized++`` blocks are still considered empty even with comments because they can still affect program flow.

rules/S108/javascript/rule.adoc

@@ -8,4 +8,4 @@ for (var i = 0; i < length; i++) {}  // Empty on purpose or missing piece of cod
 
 == Exceptions
 
-When a block contains a comment, this block is not considered to be empty. Moreover ``catch`` blocks are ignored.
+When a block contains a comment, this block is not considered to be empty. Moreover ``++catch++`` blocks are ignored.

rules/S108/kotlin/rule.adoc

@@ -5,7 +5,7 @@ include::../noncompliant.adoc[]
 == Exceptions
 
 When a block contains a comment, this block is not considered to be empty.
-``while`` and unless loops are also exception to the rule.
+``++while++`` and unless loops are also exception to the rule.
 
 ----
 while (order.processNext());  // Compliant

rules/S108/ruby/rule.adoc

@@ -26,7 +26,7 @@ end
 == Exceptions
 
 When a block contains a comment, this block is not considered to be empty.
-``while`` and ``unless`` loops are also exception to the rule.
+``++while++`` and ``++unless++`` loops are also exception to the rule.
 
 ----
 while @order.process_next; end # Compliant

rules/S1081/rule.adoc

@@ -1,11 +1,11 @@
 When using typical C functions, it's up to the developer to make sure the size of the buffer to be written to is large enough to avoid buffer overflows. Buffer overflows can cause the program to crash at a minimum. At worst, a carefully crafted overflow can cause malicious code to be executed.
 
-This rule reports use of the following insecure functions, for which knowing the required size is not generally possible: ``gets()`` and ``getpw()``.
+This rule reports use of the following insecure functions, for which knowing the required size is not generally possible: ``++gets()++`` and ``++getpw()++``.
 
 In such cases, it's better to use an alternate, secure function which allows you to define the maximum number of characters to be written to the buffer:
 
-* ``fgets`` or ``gets_s``
-* ``getpwuid``
+* ``++fgets++`` or ``++gets_s++``
+* ``++getpwuid++``
 
 
 == Noncompliant Code Example

rules/S1082/rule.adoc

@@ -3,11 +3,11 @@ Offering the same experience with the mouse and the keyboard allow users to pick
 
 This rule raises an issue when:
 
-* an HTML element with an ``onMouseover`` attribute doesn't also have an ``onFocus attribute.``
-* an HTML element with an ``onMouseout`` attribute doesn't also have an ``onBlur attribute.``
-* an HTML element with an ``onClick`` attribute doesn't also have one of the following attributes: ``onKeyDown``, ``onKeyUp``, ``onKeyPress``.
+* an HTML element with an ``++onMouseover++`` attribute doesn't also have an ``++onFocus attribute.++``
+* an HTML element with an ``++onMouseout++`` attribute doesn't also have an ``++onBlur attribute.++``
+* an HTML element with an ``++onClick++`` attribute doesn't also have one of the following attributes: ``++onKeyDown++``, ``++onKeyUp++``, ``++onKeyPress++``.
 
-Note that in the case of ``onClick``, the equivalent keyboard handler should support both the "Enter" and "Space" keys as these are usually used by screen-readers.
+Note that in the case of ``++onClick++``, the equivalent keyboard handler should support both the "Enter" and "Space" keys as these are usually used by screen-readers.
 
 
 == Noncompliant Code Example
@@ -21,7 +21,7 @@ Note that in the case of ``onClick``, the equivalent keyboard handler should su
 
 == Compliant Solution
 
-Note that setting the ``tabindex`` attribute is necessary to make the ``<div>`` element focusable.
+Note that setting the ``++tabindex++`` attribute is necessary to make the ``++<div>++`` element focusable.
 
 ----
 <div onClick="doSomething();" onKeyDown="doSomething();" tabindex="0" ...>    <!-- Compliant -->
@@ -32,9 +32,9 @@ Note that setting the ``tabindex`` attribute is necessary to make the ``<div>``
 
 == Exceptions
 
-For the following elements, https://www.w3.org/TR/WCAG20-TECHS/SCR35.html[pressing a key will trigger the ``onClick`` attribute]: ``<input type="button">``, ``<input type="submit">``, ``<button>``, ``<a>``. Thus no issue will be raised when an ``onClick`` attribute is found in these elements without a ``onKeyDown/onKeyUp/onKeyPress``.
+For the following elements, https://www.w3.org/TR/WCAG20-TECHS/SCR35.html[pressing a key will trigger the ``++onClick++`` attribute]: ``++<input type="button">++``, ``++<input type="submit">++``, ``++<button>++``, ``++<a>++``. Thus no issue will be raised when an ``++onClick++`` attribute is found in these elements without a ``++onKeyDown/onKeyUp/onKeyPress++``.
 
-An issue will still be raised for https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/button_role[elements with the ``role="button"`` attribute] as they don't behave the same way.
+An issue will still be raised for https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/button_role[elements with the ``++role="button"++`` attribute] as they don't behave the same way.
 
 
 == See

rules/S1083/rule.adoc

@@ -1,20 +1,20 @@
 With the advent of HTML5, many old elements were deprecated. To ensure the best user experience, deprecated elements should not be used. This rule checks for the following deprecated elements:
 
 ||Element||Remediation Action||
-|``basefont``, ``big``, ``blink``, ``center``, ``font``, ``marquee``, ``multicol``, ``nobr``, ``spacer``, ``tt``|use CSS|
-|``acronym``|use ``abbr``|
-|``applet``|use ``embed`` or ``object``|
-|``bgsound``|use ``audio``|
-|``frame``, ``frameset``, ``noframes``|restructure the page to remove frames|
-|``isindex``|use form controls|
-|``dir``|use ``ul``|
-|``hgroup``|use ``header`` or ``div``|
-|``listing``|use ``pre`` and ``code``|
-|``nextid``|use GUIDS|
-|``noembed``|use ``object`` instead of ``embed`` when fallback is necessary|
-|``plaintext``|use the "text/plain" MIME type|
-|``strike``|use ``del`` or ``s``|
-|``xmp``|use ``pre`` or ``code``, and escape "<" and "&" characters|
+|``++basefont++``, ``++big++``, ``++blink++``, ``++center++``, ``++font++``, ``++marquee++``, ``++multicol++``, ``++nobr++``, ``++spacer++``, ``++tt++``|use CSS|
+|``++acronym++``|use ``++abbr++``|
+|``++applet++``|use ``++embed++`` or ``++object++``|
+|``++bgsound++``|use ``++audio++``|
+|``++frame++``, ``++frameset++``, ``++noframes++``|restructure the page to remove frames|
+|``++isindex++``|use form controls|
+|``++dir++``|use ``++ul++``|
+|``++hgroup++``|use ``++header++`` or ``++div++``|
+|``++listing++``|use ``++pre++`` and ``++code++``|
+|``++nextid++``|use GUIDS|
+|``++noembed++``|use ``++object++`` instead of ``++embed++`` when fallback is necessary|
+|``++plaintext++``|use the "text/plain" MIME type|
+|``++strike++``|use ``++del++`` or ``++s++``|
+|``++xmp++``|use ``++pre++`` or ``++code++``, and escape "<" and "&" characters|
 
 
 == See

rules/S1085/rule.adoc

@@ -1,17 +1,17 @@
 In order to be accessible to visually impaired users, it is important that tables provides a description of its content before the data is accessed.
 
-The simplest way to do it, and also the one https://www.w3.org/TR/WCAG20-TECHS/H39[recommended by WCAG2] is to add a ``<caption>`` element inside the ``<table>``.
+The simplest way to do it, and also the one https://www.w3.org/TR/WCAG20-TECHS/H39[recommended by WCAG2] is to add a ``++<caption>++`` element inside the ``++<table>++``.
 
 Other technics this rule accepts are:
 
-* adding a concise description via https://www.w3.org/TR/wai-aria/#aria-label[``aria-label``] or https://www.w3.org/TR/wai-aria/#aria-labelledby[``aria-labelledby``] attributes in the ``<table>``.
-* referencing a description element with an https://www.w3.org/TR/wai-aria/#aria-describedby[``aria-describedby``] attribute in the ``<table>``.
-* embedding the ``<table>`` inside a ``<figure>`` which also contains a ``<figcaption>``.
-* adding a ``summary`` attribute to the ``<table>`` tag. However note that this attribute has been deprecated in HTML5.
+* adding a concise description via https://www.w3.org/TR/wai-aria/#aria-label[``++aria-label++``] or https://www.w3.org/TR/wai-aria/#aria-labelledby[``++aria-labelledby++``] attributes in the ``++<table>++``.
+* referencing a description element with an https://www.w3.org/TR/wai-aria/#aria-describedby[``++aria-describedby++``] attribute in the ``++<table>++``.
+* embedding the ``++<table>++`` inside a ``++<figure>++`` which also contains a ``++<figcaption>++``.
+* adding a ``++summary++`` attribute to the ``++<table>++`` tag. However note that this attribute has been deprecated in HTML5.
 
 See https://www.w3.org/WAI/tutorials/tables/tips/[W3C WAI Web Accessibility Tutorials] for more information.
 
-This rule raises an issue when a ``<table>`` has neither of the previously mentioned description mechanisms.
+This rule raises an issue when a ``++<table>++`` has neither of the previously mentioned description mechanisms.
 
 
 == Noncompliant Code Example
@@ -25,7 +25,7 @@ This rule raises an issue when a ``<table>`` has neither of the previously menti
 
 == Compliant Solution
 
-Adding a ``<caption>`` element.
+Adding a ``++<caption>++`` element.
 
 ----
 <table>
@@ -33,7 +33,7 @@ Adding a ``<caption>`` element.
   ...
 </table>
 ----
-Adding an ``aria-describedby`` attribute.
+Adding an ``++aria-describedby++`` attribute.
 
 ----
 <p id="mydesc">New York City Marathon Results 2013</p>
@@ -41,7 +41,7 @@ Adding an ``aria-describedby`` attribute.
   ...
 </table>
 ----
-Embedding the table in a ``<figure>`` which also contains a ``<figcaption>``.
+Embedding the table in a ``++<figure>++`` which also contains a ``++<figcaption>++``.
 
 ----
 <figure>
@@ -51,7 +51,7 @@ Embedding the table in a ``<figure>`` which also contains a ``<figcaption>``.
   </table>
 </figure>
 ----
-Adding a ``summary`` attribute. However note that this attribute has been deprecated in HTML5.
+Adding a ``++summary++`` attribute. However note that this attribute has been deprecated in HTML5.
 
 ----
 <table summary="New York City Marathon Results 2013">
@@ -62,9 +62,9 @@ Adding a ``summary`` attribute. However note that this attribute has been depre
 
 == Exceptions
 
-No issue will be raised on ``<table>`` used for layout purpose, i.e. when it contains a ``role`` attribute set to ``"presentation"`` or ``"none"``. Note that using ``<table>`` for layout purpose is a bad practice.
+No issue will be raised on ``++<table>++`` used for layout purpose, i.e. when it contains a ``++role++`` attribute set to ``++"presentation"++`` or ``++"none"++``. Note that using ``++<table>++`` for layout purpose is a bad practice.
 
-No issue will be raised either on ``<table>`` containing an ``aria-hidden`` attribute set to ``"true"``.
+No issue will be raised either on ``++<table>++`` containing an ``++aria-hidden++`` attribute set to ``++"true"++``.
 
 
 == See

rules/S1086/rule.adoc

@@ -1,5 +1,5 @@
 Heading tags are used by search engines and screen reader softwares to construct an outline of the page.
-Starting at ``<h1>`` and not skipping any level eases this automatic construction.
+Starting at ``++<h1>++`` and not skipping any level eases this automatic construction.
 
 
 == Noncompliant Code Example

rules/S1087/rule.adoc

@@ -1,6 +1,6 @@
-The ``<object>`` tag is used by Internet Explorer 3.0 or later on Windows platforms or any browser that supports the use of the Flash ActiveX control. The ``<embed>`` tag is used by Netscape Navigator 2.0 or later, or browsers that support the use of the Netscape-compatible plug-in version of Flash Player.
+The ``++<object>++`` tag is used by Internet Explorer 3.0 or later on Windows platforms or any browser that supports the use of the Flash ActiveX control. The ``++<embed>++`` tag is used by Netscape Navigator 2.0 or later, or browsers that support the use of the Netscape-compatible plug-in version of Flash Player.
 
-When an ActiveX-enabled browser loads the HTML page, it reads the values set on the ``<object>`` and ignores the ``<embed>`` tag. When browsers using the Flash plug-in load the HTML page, they read the values set on the ``<embed>`` tag and ignore the ``<object>`` tag.
+When an ActiveX-enabled browser loads the HTML page, it reads the values set on the ``++<object>++`` and ignores the ``++<embed>++`` tag. When browsers using the Flash plug-in load the HTML page, they read the values set on the ``++<embed>++`` tag and ignore the ``++<object>++`` tag.
 
 
 == Noncompliant Code Example

rules/S1088/rule.adoc

@@ -1,5 +1,5 @@
-Browsers best support the ``window`` mode for the ``wmode`` parameter, also in terms of accessibility.
-As it is the default mode, it is acceptable to either not specify a ``wmode`` parameter altogether, or to set it explicitly to ``window``.
+Browsers best support the ``++window++`` mode for the ``++wmode++`` parameter, also in terms of accessibility.
+As it is the default mode, it is acceptable to either not specify a ``++wmode++`` parameter altogether, or to set it explicitly to ``++window++``.
 
 
 == Noncompliant Code Example

rules/S109/cfamily/rule.adoc

@@ -2,7 +2,7 @@ A magic number is a number that comes out of nowhere, and is directly used in a
 
 Using magic numbers may seem obvious and straightforward when you're writing a piece of code, but they are much less obvious and straightforward at debugging time.
 
-That is why magic numbers must be demystified by first being assigned a name. This is classically done by using a constant (``constexpr`` or ``const`` if your compiler does not support ``constexpr`` yet) or an enumeration.
+That is why magic numbers must be demystified by first being assigned a name. This is classically done by using a constant (``++constexpr++`` or ``++const++`` if your compiler does not support ``++constexpr++`` yet) or an enumeration.
 
 -1, 0 and 1 are not considered magic numbers.
 

rules/S109/csharp/rule.adoc

@@ -28,4 +28,4 @@ public static void DoSomething()
 
 == Exceptions
 
-This rule doesn't raise an issue when the magic number is used as part of the ``GetHashCode`` method or a variable/field declaration.
+This rule doesn't raise an issue when the magic number is used as part of the ``++GetHashCode++`` method or a variable/field declaration.

rules/S109/java/rule.adoc

@@ -23,4 +23,4 @@ public static void doSomething() {
 
 == Exceptions
 
-This rule ignores ``hashCode`` methods.
+This rule ignores ``++hashCode++`` methods.

rules/S1090/rule.adoc

@@ -1,6 +1,6 @@
 Frames allow different web pages to be put together on the same visual space. Users without disabilities can easily scan the contents of all frames at once. However, visually impaired users using screen readers hear the page content linearly.
 
-The ``title`` attribute is used to list all the page's frames, enabling those users to easily navigate among them. Therefore, the ``<frame>`` and ``<iframe>`` tags should always have a ``title`` attribute.
+The ``++title++`` attribute is used to list all the page's frames, enabling those users to easily navigate among them. Therefore, the ``++<frame>++`` and ``++<iframe>++`` tags should always have a ``++title++`` attribute.
 
 
 == Noncompliant Code Example

rules/S1091/rule.adoc

@@ -1,6 +1,6 @@
-The ``ismap`` attribute in an ``img`` tag creates a server-side image map: The browser sends the coordinates of the clicked point to the server.
+The ``++ismap++`` attribute in an ``++img++`` tag creates a server-side image map: The browser sends the coordinates of the clicked point to the server.
 For any person who cannot use a mouse, this form of navigation is inaccessible because it is the position of the cursor on the image that determines the action.
-On the other hand, client-side image maps, which use the ``usemap`` attribute allow for each clickable area to specify an alternate text, enabling accessibility for the blind.
+On the other hand, client-side image maps, which use the ``++usemap++`` attribute allow for each clickable area to specify an alternate text, enabling accessibility for the blind.
 Further, in terms of separation of concerns, it is definitely better to leave the task of mapping pixels to links to the client.
 
 

rules/S1092/rule.adoc

@@ -1,9 +1,9 @@
 Whenever a user clicks on a link that targets an image, the website's navigation menu will be lost.
 From a user point of view, it is as if she left the website.
 The only way to return to it is using the browser's 'Back' button.
-Instead, it is better to create a page which will display the image using the ``<img>`` tag and preserve the navigation menu.
+Instead, it is better to create a page which will display the image using the ``++<img>++`` tag and preserve the navigation menu.
 
-Further, in terms of accessibility, when the image is embedded into a page, content providers are able to provide an alternate text equivalent through the ``alt`` attribute.
+Further, in terms of accessibility, when the image is embedded into a page, content providers are able to provide an alternate text equivalent through the ``++alt++`` attribute.
 
 
 == Noncompliant Code Example

rules/S1093/rule.adoc

@@ -1,4 +1,4 @@
-Using a ``<li>`` or ``<dt>`` item tag outside of a ``<ul>``, ``<ol>`` or ``<dl>`` one does not make sense and indicates a bug.
+Using a ``++<li>++`` or ``++<dt>++`` item tag outside of a ``++<ul>++``, ``++<ol>++`` or ``++<dl>++`` one does not make sense and indicates a bug.
 
 
 == Noncompliant Code Example

rules/S1094/rule.adoc

@@ -1,4 +1,4 @@
-Use of ``<meta http-equiv="refresh">`` is discouraged by the World Wide Web Consortium (W3C).
+Use of ``++<meta http-equiv="refresh">++`` is discouraged by the World Wide Web Consortium (W3C).
 If a user clicks the 'Back' button, some browers will go back to the redirecting page, which will prevent the user from actually going back.
 
 To refresh the page, a better alternative is to use Ajax, to refresh only what needs to be refreshed and not the whole page.

rules/S1095/rule.adoc

@@ -1,6 +1,6 @@
-The ``<!DOCTYPE>`` declaration tells the web browser which (X)HTML version is being used on the page, and therefore how to interpret the various elements.
+The ``++<!DOCTYPE>++`` declaration tells the web browser which (X)HTML version is being used on the page, and therefore how to interpret the various elements.
 Validators also rely on it to know which rules to enforce.
-It should always preceed the ``<html>`` tag.
+It should always preceed the ``++<html>++`` tag.
 
 
 == Noncompliant Code Example

rules/S1096/rule.adoc

@@ -1,6 +1,6 @@
 Titles are important because they are displayed in search engine results as well as the browser's toolbar.
 
-This rule verifies that the ``<head>`` tag contains a ``<title>`` one, and the ``<html>`` tag a ``<head>`` one.
+This rule verifies that the ``++<head>++`` tag contains a ``++<title>++`` one, and the ``++<html>++`` tag a ``++<head>++`` one.
 
 
 == Noncompliant Code Example

rules/S1097/rule.adoc

@@ -1,14 +1,14 @@
-The ``<label>`` tag defines a label for ``<input>``, ``<select>`` and ``<textarea>`` elements.
+The ``++<label>++`` tag defines a label for ``++<input>++``, ``++<select>++`` and ``++<textarea>++`` elements.
 
-The ``<label>`` tag improves usability for visually impaired users: Screen readers will announce the label text whenever the focus is set on the input field.
+The ``++<label>++`` tag improves usability for visually impaired users: Screen readers will announce the label text whenever the focus is set on the input field.
 
-It also improves usability for users with impaired motor control: when the text within the ``<label>`` element is clicked, the associated input field is toggled.
+It also improves usability for users with impaired motor control: when the text within the ``++<label>++`` element is clicked, the associated input field is toggled.
 
-In most cases, ``for`` attribute of the ``<label>`` tag should be equal to the ``id`` attribute of the related element to bind them together.
+In most cases, ``++for++`` attribute of the ``++<label>++`` tag should be equal to the ``++id++`` attribute of the related element to bind them together.
 
-Sometimes the field is explained by an icon. In this case the label can be either hidden or the ``<input>``, ``<select>`` or ``<textarea>`` tags should contain one of the following attributes: ``aria-label``, ``aria-labelledby``. Screen-readers will use those attributes to describe the field.
+Sometimes the field is explained by an icon. In this case the label can be either hidden or the ``++<input>++``, ``++<select>++`` or ``++<textarea>++`` tags should contain one of the following attributes: ``++aria-label++``, ``++aria-labelledby++``. Screen-readers will use those attributes to describe the field.
 
-The purpose of this rule is to make sure that every ``input`` (except ``submit``, ``button``, ``image``, and ``hidden`` inputs), ``select``, and ``textarea`` field has a label.
+The purpose of this rule is to make sure that every ``++input++`` (except ``++submit++``, ``++button++``, ``++image++``, and ``++hidden++`` inputs), ``++select++``, and ``++textarea++`` field has a label.
 
 
 == Noncompliant Code Example
@@ -54,7 +54,7 @@ The purpose of this rule is to make sure that every ``input`` (except ``submit``
 
 == Exceptions
 
-No issue will be raised on "implicit labels", i.e. ``<label>`` tags enclosing an ``<input>``, ``<select>`` or ``<textarea>`` instead of being referencing via an ``id``. However, note that the support of this technic is not supported by all assistive technologies. Thus it is better to reference them by id.
+No issue will be raised on "implicit labels", i.e. ``++<label>++`` tags enclosing an ``++<input>++``, ``++<select>++`` or ``++<textarea>++`` instead of being referencing via an ``++id++``. However, note that the support of this technic is not supported by all assistive technologies. Thus it is better to reference them by id.
 
 ----
 <label>

rules/S1099/rule.adoc

@@ -1,4 +1,4 @@
-If the ``width`` and ``height`` attributes are set, the space required for the image is reserved immediately by the browser, even before it actually starts to load the image.
+If the ``++width++`` and ``++height++`` attributes are set, the space required for the image is reserved immediately by the browser, even before it actually starts to load the image.
 Without those attributes, the page layout constantly changes as images are loaded until they are all loaded, which can disorient users.
 
 

rules/S110/description.adoc

@@ -1,3 +1,3 @@
 Inheritance is certainly one of the most valuable concepts in object-oriented programming. It's a way to compartmentalize and reuse code by creating collections of attributes and behaviors called classes which can be based on previously created classes. But abusing this concept by creating a deep inheritance tree can lead to very complex and unmaintainable source code. Most of the time a too deep inheritance tree is due to bad object oriented design which has led to systematically use 'inheritance' when for instance 'composition' would suit better.
 
-This rule raises an issue when the inheritance tree, starting from ``Object`` has a greater depth than is allowed. 
+This rule raises an issue when the inheritance tree, starting from ``++Object++`` has a greater depth than is allowed. 

rules/S110/java/rule.adoc

@@ -1,15 +1,15 @@
 Inheritance is certainly one of the most valuable concepts in object-oriented programming. It's a way to compartmentalize and reuse code by creating collections of attributes and behaviors called classes which can be based on previously created classes. But abusing this concept by creating a deep inheritance tree can lead to very complex and unmaintainable source code. Most of the time a too deep inheritance tree is due to bad object oriented design which has led to systematically use 'inheritance' when for instance 'composition' would suit better.
 
-This rule raises an issue when the inheritance tree, starting from ``Object`` has a greater depth than is allowed. 
+This rule raises an issue when the inheritance tree, starting from ``++Object++`` has a greater depth than is allowed. 
 
 For the parameter of the rule, the following rules are applied:
 
-* ``?`` matches a single character
-* ``*`` matches zero or more characters
-* ``**`` matches zero or more packages
+* ``++?++`` matches a single character
+* ``++*++`` matches zero or more characters
+* ``++**++`` matches zero or more packages
 
 Examples:
 
-* ``java.fwk.AbstractFwkClass`` will stop count when AbstractFwkClassclass is reached.
-* ``java.fwkPackage.*`` will stop count when any member of java.internal package is reached.
-* ``java.fwkPackage.**`` same as above, but including sub-packages.
+* ``++java.fwk.AbstractFwkClass++`` will stop count when AbstractFwkClassclass is reached.
+* ``++java.fwkPackage.*++`` will stop count when any member of java.internal package is reached.
+* ``++java.fwkPackage.**++`` same as above, but including sub-packages.

rules/S1100/rule.adoc

@@ -1,14 +1,14 @@
-The ``<strong>``/``<b>`` and ``<em>``/``<i>`` tags have exactly the same effect in most web browsers, but there is a fundamental difference between them: ``<strong>`` and ``<em>`` have a semantic meaning whereas ``<b>`` and ``<i>`` only convey styling information like CSS.  
+The ``++<strong>++``/``++<b>++`` and ``++<em>++``/``++<i>++`` tags have exactly the same effect in most web browsers, but there is a fundamental difference between them: ``++<strong>++`` and ``++<em>++`` have a semantic meaning whereas ``++<b>++`` and ``++<i>++`` only convey styling information like CSS.  
 
-While ``<b>`` can have simply no effect on a some devices with limited display or when a screen reader software is used by a blind person, ``<strong>`` will:
+While ``++<b>++`` can have simply no effect on a some devices with limited display or when a screen reader software is used by a blind person, ``++<strong>++`` will:
 
 * Display the text bold in normal browsers
 * Speak with lower tone when using a screen reader such as Jaws
 
 Consequently:
 
-* in order to convey semantics, the ``<b>`` and ``<i>`` tags shall never be used,
-* in order to convey styling information, the ``<b>`` and ``<i>`` should be avoided and CSS should be used instead.
+* in order to convey semantics, the ``++<b>++`` and ``++<i>++`` tags shall never be used,
+* in order to convey styling information, the ``++<b>++`` and ``++<i>++`` should be avoided and CSS should be used instead.
 
 
 == Noncompliant Code Example

rules/S1102/rule.adoc

@@ -1,15 +1,15 @@
-Associating ``<table>`` headers, i.e. ``<th>`` elements, with their ``<td>`` cells enables screen readers to announce the header prior to the data. This considerably increases the accessibility of tables to visually impaired users.
+Associating ``++<table>++`` headers, i.e. ``++<th>++`` elements, with their ``++<td>++`` cells enables screen readers to announce the header prior to the data. This considerably increases the accessibility of tables to visually impaired users.
 
 There are two ways of doing it:
 
-* Adding a ``scope`` attribute to ``<th>`` headers.
-* Adding an ``id`` attribute to ``<th>`` headers and a ``headers`` attribute to every ``<td>`` element.
+* Adding a ``++scope++`` attribute to ``++<th>++`` headers.
+* Adding an ``++id++`` attribute to ``++<th>++`` headers and a ``++headers++`` attribute to every ``++<td>++`` element.
 
-It is recommended to add ``scope`` attributes to ``<th>`` headers whenever possible. Use ``<th id="...">`` and ``<td headers="...">`` only when ``<th scope="...">`` is not capable of associating cells to their headers. This happens for very complex tables which have headers splitting the data in multiple subtables. See https://www.w3.org/WAI/tutorials/tables/tips/[W3C WAI Web Accessibility Tutorials] for more information.
+It is recommended to add ``++scope++`` attributes to ``++<th>++`` headers whenever possible. Use ``++<th id="...">++`` and ``++<td headers="...">++`` only when ``++<th scope="...">++`` is not capable of associating cells to their headers. This happens for very complex tables which have headers splitting the data in multiple subtables. See https://www.w3.org/WAI/tutorials/tables/tips/[W3C WAI Web Accessibility Tutorials] for more information.
 
 Note that complex tables can often be split into multiple smaller tables, which improves the user experience.
 
-This rule raises an issue when a ``<th>`` element has neither ``id`` nor ``scope`` attributes set.
+This rule raises an issue when a ``++<th>++`` element has neither ``++id++`` nor ``++scope++`` attributes set.
 
 
 == Noncompliant Code Example

rules/S1103/description.adoc

@@ -1,4 +1,4 @@
 Defining a nested single-line comment within a multi-line comment invites errors. It may lead a developer to wrongly think that the lines located after the single-line comment are not part of the comment.
 
-If a comment starting sequence, ``/*`` or ``//``, occurs within a ``/*`` comment, is it quite likely to be caused by a missing ``*/`` comment ending sequence.
-If a comment starting sequence occurs within a ``//`` comment, it is probably because a region of code has been commented-out using ``//``.
+If a comment starting sequence, ``++/*++`` or ``++//++``, occurs within a ``++/*++`` comment, is it quite likely to be caused by a missing ``++*/++`` comment ending sequence.
+If a comment starting sequence occurs within a ``++//++`` comment, it is probably because a region of code has been commented-out using ``++//++``.