diff --git a/java/ql/src/Likely Bugs/Concurrency/UnreleasedLock.qhelp b/java/ql/src/Likely Bugs/Concurrency/UnreleasedLock.qhelp
index eb8dd211083..e3029c6249d 100644
--- a/java/ql/src/Likely Bugs/Concurrency/UnreleasedLock.qhelp	
+++ b/java/ql/src/Likely Bugs/Concurrency/UnreleasedLock.qhelp	
@@ -6,7 +6,7 @@
 <overview>
 <p>
 When a thread acquires a lock it must make sure to unlock it again;
-failing to do so can lead to deadlocks.  If a lock allows a thread to acquire
+failing to do so can lead to deadlocks. If a lock allows a thread to acquire
 it multiple times, for example <code>java.util.concurrent.locks.ReentrantLock</code>,
 then the number of locks must match the number of unlocks in order to fully
 release the lock.
@@ -17,7 +17,7 @@ release the lock.
 <p>
 It is recommended practice always to immediately follow a call to <code>lock</code>
 with a <code>try</code> block and place the call to <code>unlock</code> inside the
-<code>finally</code> block.  Beware of calls inside the <code>finally</code> block
+<code>finally</code> block. Beware of calls inside the <code>finally</code> block
 that could cause exceptions, as this may result in skipping the call to <code>unlock</code>.
 </p>
 </recommendation>