Merge pull request #244 from microsoft/lwsimpkins/fix-qhelp

fix failing qhelp files

cpp/ql/src/Likely Bugs/Leap Year/LeapYearConditionalLogic.qhelp

@@ -15,7 +15,7 @@
 </recommendation>
 <example>
 <p>Note in the following examples, that year, month, and day might instead be .wYear, .wMonth, and .wDay fields of a SYSTEMTIME structure, or might be .tm_year, .tm_mon, and .tm_mday fields of a struct tm.</p>
-<sample src="LeapYearConditionalLogicBad.c" />
+<sample src="examples/LeapYearConditionalLogicBad.c" />
 </example>
 
 <references>

cpp/ql/src/Metrics/Classes/CNumberOfFunctions.qhelp

@@ -49,21 +49,16 @@ need to be part of the class. (A classic example of this is the
 observes, there are at least two key problems with this approach:
 
 
-<ul>
-<li>
-It may be possible to generalize some of the utility functions beyond the
+<i>1. It may be possible to generalize some of the utility functions beyond the
 narrow context of the class in question -- by bundling them with the class,
 the class author reduces the scope for functionality reuse.
-</li>
 
-<li>
-It's usually impossible for the class author to know every possible
+2. It's usually impossible for the class author to know every possible
 operation that the user might want to perform on the class, so the public
 interface will inherently be incomplete. New utility functions will end up
 having a different syntax to the privileged public functions in the class,
 negatively impacting on code consistency.
-</li>
-</ul>
+</i>
 
 To refactor a class like this, simply move its utility functions elsewhere,
 paring its public interface down to the bare minimum.

cpp/ql/src/Metrics/Classes/CSizeOfAPI.qhelp

@@ -46,21 +46,17 @@ need to be part of the class. (A classic example of this is the
 <code>std::string</code> class in the C++ Standard Library.) As [Sutter]
 observes, there are at least two key problems with this approach:
 
-<ul>
-<li>
-It may be possible to generalize some of the utility functions beyond the
+<i>
+1. It may be possible to generalize some of the utility functions beyond the
 narrow context of the class in question -- by bundling them with the class,
 the class author reduces the scope for functionality reuse.
-</li>
 
-<li>
-It's usually impossible for the class author to know every possible
+2. It's usually impossible for the class author to know every possible
 operation that the user might want to perform on the class, so the public
 interface will inherently be incomplete. New utility functions will end up
 having a different syntax to the privileged public functions in the class,
 negatively impacting on code consistency.
-</li>
-</ul>
+</i>
 
 To refactor a class like this, simply move its utility functions elsewhere,
 paring its public interface down to the bare minimum.

java/ql/src/Metrics/RefTypes/TInheritanceDepth.qhelp

@@ -29,14 +29,13 @@ that something is amiss, but further investigation will be needed to clarify
 the cause of the problem. Here are two possibilities:
 </p>
 
-<ul>
-
-<li>
-A class and its superclass represent fundamentally the same abstraction.
+<p>
+1. A class and its superclass represent fundamentally the same abstraction.
 In this case, they should generally be merged together (see the 'Collapse
 Hierarchy' refactoring on pp.279-80 of [Fowler]). For example, suppose
 that in the following class hierarchy both A and C represent fundamentally
 the same thing, then they should be merged together as shown:
+</p>
 
 <table>
 <tbody><tr>
@@ -48,11 +47,9 @@ the same thing, then they should be merged together as shown:
 <td>After</td>
 </tr>
 </tbody></table>
-</li>
 
-<li>
 <p>
-The class hierarchy is trying to represent variation in more than one
+2. The class hierarchy is trying to represent variation in more than one
 dimension using single inheritance. This can lead to an unnecessarily
 deep class hierarchy with lots of code duplication. For example, consider
 the following:
@@ -81,9 +78,6 @@ amount of code duplication that will be necessary.
 For readers who are interested in this sort of approach, a good reference is
 [West].
 </p>
-</li>
-
-</ul>
 
 
 

java/ql/src/Metrics/RefTypes/TNumberOfCallables.qhelp

@@ -49,21 +49,17 @@ need to be part of the class. (A classic example of this is the
 <code>std::string</code> class in the C++ Standard Library.) As [Sutter]
 observes, there are at least two key problems with this approach:
 
-<ul>
-<li>
-It may be possible to generalize some of the utility methods beyond the
+<i>
+1. It may be possible to generalize some of the utility methods beyond the
 narrow context of the class in question -- by bundling them with the class,
 the class author reduces the scope for functionality reuse.
-</li>
 
-<li>
-It's usually impossible for the class author to know every possible
+2. It's usually impossible for the class author to know every possible
 operation that the user might want to perform on the class, so the public
 interface will inherently be incomplete. New utility methods will end up
 having a different syntax to the privileged public methods in the class,
 negatively impacting on code consistency.
-</li>
-</ul>
+</i>
 
 To refactor a class like this, simply move its utility methods elsewhere,
 paring its public interface down to the bare minimum.

java/ql/src/Metrics/RefTypes/TNumberOfFields.qhelp

@@ -25,11 +25,9 @@ If the class is too big, you should split it into multiple smaller classes.
 </li>
 
 <li>
-<p>
 If several of the fields are part of the same abstraction, you should
 group them into a separate class, using the 'Extract Class' refactoring described
 in [Fowler].
-</p>
 </li>
 </ul>
 

java/ql/src/Metrics/RefTypes/TSizeOfAPI.qhelp

@@ -46,21 +46,17 @@ need to be part of the class. (A classic example of this is the
 <code>std::string</code> class in the C++ Standard Library.) As [Sutter]
 observes, there are at least two key problems with this approach:
 
-<ul>
-<li>
-It may be possible to generalize some of the utility methods beyond the
+<i>
+1. It may be possible to generalize some of the utility methods beyond the
 narrow context of the class in question -- by bundling them with the class,
 the class author reduces the scope for functionality reuse.
-</li>
 
-<li>
-It's usually impossible for the class author to know every possible
+2. It's usually impossible for the class author to know every possible
 operation that the user might want to perform on the class, so the public
 interface will inherently be incomplete. New utility methods will end up
 having a different syntax to the privileged public methods in the class,
 negatively impacting on code consistency.
-</li>
-</ul>
+</i>
 
 To refactor a class like this, simply move its utility methods elsewhere,
 paring its public interface down to the bare minimum.