From f96a250ffc511b3d710ef2cb26b896c27aa520f3 Mon Sep 17 00:00:00 2001
From: Lindsay Simpkins <lsimpkins@microsoft.com>
Date: Mon, 9 Jun 2025 18:36:44 -0400
Subject: [PATCH] fix qhelp files

---
 .../src/Metrics/Classes/CNumberOfFunctions.qhelp   | 11 +++--------
 cpp/ql/src/Metrics/Classes/CSizeOfAPI.qhelp        | 12 ++++--------
 .../src/Metrics/RefTypes/TInheritanceDepth.qhelp   | 14 ++++----------
 .../src/Metrics/RefTypes/TNumberOfCallables.qhelp  | 12 ++++--------
 java/ql/src/Metrics/RefTypes/TNumberOfFields.qhelp |  2 --
 java/ql/src/Metrics/RefTypes/TSizeOfAPI.qhelp      | 12 ++++--------
 6 files changed, 19 insertions(+), 44 deletions(-)

diff --git a/cpp/ql/src/Metrics/Classes/CNumberOfFunctions.qhelp b/cpp/ql/src/Metrics/Classes/CNumberOfFunctions.qhelp
index cc62cb50f498..8ef045c70923 100644
--- a/cpp/ql/src/Metrics/Classes/CNumberOfFunctions.qhelp
+++ b/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.
diff --git a/cpp/ql/src/Metrics/Classes/CSizeOfAPI.qhelp b/cpp/ql/src/Metrics/Classes/CSizeOfAPI.qhelp
index 0d560f920aa6..70c4c862fb61 100644
--- a/cpp/ql/src/Metrics/Classes/CSizeOfAPI.qhelp
+++ b/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.
diff --git a/java/ql/src/Metrics/RefTypes/TInheritanceDepth.qhelp b/java/ql/src/Metrics/RefTypes/TInheritanceDepth.qhelp
index 7d78490985bf..970b1c4e19e2 100644
--- a/java/ql/src/Metrics/RefTypes/TInheritanceDepth.qhelp
+++ b/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>
 
 
 
diff --git a/java/ql/src/Metrics/RefTypes/TNumberOfCallables.qhelp b/java/ql/src/Metrics/RefTypes/TNumberOfCallables.qhelp
index 49827592849d..4f9452789a89 100644
--- a/java/ql/src/Metrics/RefTypes/TNumberOfCallables.qhelp
+++ b/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.
diff --git a/java/ql/src/Metrics/RefTypes/TNumberOfFields.qhelp b/java/ql/src/Metrics/RefTypes/TNumberOfFields.qhelp
index befc6409449e..2934ba958b52 100644
--- a/java/ql/src/Metrics/RefTypes/TNumberOfFields.qhelp
+++ b/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>
 
diff --git a/java/ql/src/Metrics/RefTypes/TSizeOfAPI.qhelp b/java/ql/src/Metrics/RefTypes/TSizeOfAPI.qhelp
index 3095d82049a6..eda183a287c2 100644
--- a/java/ql/src/Metrics/RefTypes/TSizeOfAPI.qhelp
+++ b/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.