Docs: Use GitHub links for guides, improve formatting

docs/ql-style-guide.md

@@ -3,7 +3,7 @@
 ## Introduction
 
 This document describes how to format the code you contribute to this repository. It covers aspects such as layout, white-space, naming, and documentation. Adhering to consistent standards makes code easier to read and maintain. Of course, these are only guidelines, and can be overridden as the need arises on a case-by-case basis. Where existing code deviates from these guidelines, prefer consistency with the surrounding code.
-Note, if you use [CodeQL for Visual Studio Code](https://help.semmle.com/codeql/codeql-for-vscode/procedures/about-codeql-for-vscode.html), you can autoformat your query in the editor.
+Note, if you use [CodeQL for Visual Studio Code](https://codeql.github.com/docs/codeql-for-visual-studio-code/about-codeql-for-visual-studio-code/), you can autoformat your query in the editor.
 
 Words in *italic* are defined in the [Glossary](#glossary).
 
@@ -166,7 +166,7 @@ private predicate foo(Expr e, Expr p) {
 ```
 
 ## Naming
-1. Use [PascalCase](http://wiki.c2.com/?PascalCase) for:
+1. Use [PascalCase](https://wiki.c2.com/?PascalCase) for:
    - `class` names
    - `module` names
    - `newtype` names
@@ -249,7 +249,7 @@ For more information about documenting the code that you contribute to this repo
 1. The `and` and `else` keywords *may* be placed on the same line as the closing parenthesis.
 1. The `and` and `else` keywords *may* be "cuddled": `) else (`
 1. *Always* qualify *calls* to predicates of the same class with `this`.
-2. *Prefer* postfix casts `a.(Expr)` to prefix casts `(Expr)a`.
+1. *Prefer* postfix casts `a.(Expr)` to prefix casts `(Expr)a`.
 
 ### Examples
 
@@ -350,16 +350,16 @@ For more information about documenting the code that you contribute to this repo
 
 | Phrase      | Meaning  |
 |-------------|----------|
-| *[annotation](https://help.semmle.com/QL/ql-handbook/language.html#annotations)* | An additional specifier used to modify a declaration, such as `private`, `override`, `deprecated`, `pragma`, `bindingset`, or `cached`. |
+| *[annotation](https://codeql.github.com/docs/ql-language-reference/ql-language-specification/#annotations)* | An additional specifier used to modify a declaration, such as `private`, `override`, `deprecated`, `pragma`, `bindingset`, or `cached`. |
 | *body* | The text inside `{ }`, `( )`, or each section of an `if`-`then`-`else` or `from`-`where`-`select`. |
 | *binary operator* | An operator with two operands, such as comparison operators, `and`, `or`, `implies`, or arithmetic operators. |
 | *call* | A *formula* that invokes a predicate, e.g. `this.isStatic()` or `calls(a,b)`. |
-| *[conjunct](https://help.semmle.com/QL/ql-handbook/language.html#conjunctions)* | A formula that is an operand to an `and`. |
+| *[conjunct](https://codeql.github.com/docs/ql-language-reference/ql-language-specification/#conjunctions)* | A formula that is an operand to an `and`. |
 | *declaration* | A class, module, predicate, field or newtype. |
-| *[disjunct](https://help.semmle.com/QL/ql-handbook/language.html#disjunctions)* | A formula that is an operand to an `or`. |
-| *[formula](https://help.semmle.com/QL/ql-handbook/language.html#formulas)* | A logical expression, such as `A = B`, a *call*, a *quantifier*, `and`, `or`, `not`, `in` or `instanceof`. |
+| *[disjunct](https://codeql.github.com/docs/ql-language-reference/ql-language-specification/#disjunctions)* | A formula that is an operand to an `or`. |
+| *[formula](https://codeql.github.com/docs/ql-language-reference/ql-language-specification/#formulas)* | A logical expression, such as `A = B`, a *call*, a *quantifier*, `and`, `or`, `not`, `in` or `instanceof`. |
 | *should/should not/avoid/prefer* | Adhere to this rule wherever possible, where it makes sense. |
 | *may/can* | This is a reasonable alternative, to be used with discretion. |
 | *must/always/do not* | Always adhere to this rule. |
-| *[quantifier/aggregation](https://help.semmle.com/QL/ql-handbook/language.html#aggregations)* | `exists`, `count`, `strictcount`, `any`, `forall`, `forex` and so on. |
+| *[quantifier/aggregation](https://codeql.github.com/docs/ql-language-reference/ql-language-specification/#aggregations)* | `exists`, `count`, `strictcount`, `any`, `forall`, `forex` and so on. |
 | *variable* | A parameter to a predicate, a field, a from variable, or a variable introduced by a *quantifier* or *aggregation*. |

docs/qldoc-style-guide.md

@@ -124,11 +124,12 @@ Certain special predicates should be documented consistently.
    * The location spans column `startcolumn` of line `startline` to
    * column `endcolumn` of line `endline` in file `filepath`.
    * For more information, see
-   * [Locations](https://help.semmle.com/QL/learn-ql/locations.html).
+   * [Locations](https://codeql.github.com/docs/writing-codeql-queries/providing-locations-in-codeql-queries/).
    */
 
   predicate hasLocationInfo(string filepath, int startline, int startcolumn, int endline, int endcolumn) { ... }
   ```
+
 ## QLDoc for classes
 
 1. Document classes using a noun phrase of the form `A <domain element> that <has property>.`

docs/query-help-style-guide.md

@@ -4,11 +4,12 @@
 
 When you contribute a new [supported query](supported-queries.md) to this repository, or add a custom query for analysis in LGTM, you should also write a query help file. This file provides detailed information about the purpose and use of the query, which is available to users in LGTM (for example [here](https://lgtm.com/rules/1506093386171/)) and on the query homepages:
 
-*   [C/C++ queries](https://help.semmle.com/wiki/display/CCPPOBJ/)
-*   [C# queries](https://help.semmle.com/wiki/display/CSHARP/)
-*   [Java queries](https://help.semmle.com/wiki/display/JAVA/)
-*   [JavaScript queries](https://help.semmle.com/wiki/display/JS/)
-*   [Python queries](https://help.semmle.com/wiki/display/PYTHON/)
+* [C/C++ queries](https://codeql.github.com/codeql-query-help/cpp/)
+* [C# queries](https://codeql.github.com/codeql-query-help/csharp/)
+* [Go queries](https://codeql.github.com/codeql-query-help/go/)
+* [Java queries](https://codeql.github.com/codeql-query-help/java/)
+* [JavaScript queries](https://codeql.github.com/codeql-query-help/javascript/)
+* [Python queries](https://codeql.github.com/codeql-query-help/python/)
 
 ### Location and file name
 
@@ -18,57 +19,57 @@ Query help files must have the same base name as the query they describe and mus
 
 Query help files are written using a custom XML format, and stored in a file with a `.qhelp` extension. The basic structure is as follows:
 
-```
+```xml
 <!DOCTYPE qhelp SYSTEM "qhelp.dtd">
 <qhelp>
     CONTAINS one or more section-level elements
 </qhelp>
 ```
 
-The header and single top-level `<qhelp>` element are both mandatory. 
+The header and single top-level `<qhelp>` element are both mandatory.
 
 ### Section-level elements
 
 Section-level elements are used to group the information within the query help file. All query help files should include at least the following section elements, in the order specified:
 
-1.  `overview`—a short summary of the issue that the query identifies, including an explanation of how it could affect the behavior of the program.
-2.  `recommendation`—information on how to fix the issue highlighted by the query.
-3.  `example`—an example of code showing the problem. Where possible, this section should also include a solution to the issue.
-4.  `references`—relevant references, such as authoritative sources on language semantics and best practice. 
+1. `overview`—a short summary of the issue that the query identifies, including an explanation of how it could affect the behavior of the program.
+2. `recommendation`—information on how to fix the issue highlighted by the query.
+3. `example`—an example of code showing the problem. Where possible, this section should also include a solution to the issue.
+4. `references`—relevant references, such as authoritative sources on language semantics and best practice.
 
-For further information about the other section-level, block, list and table elements supported by query help files, see [Query help files](https://help.semmle.com/QL/learn-ql/ql/writing-queries/query-help.html) on help.semmle.com.
+For further information about the other section-level, block, list and table elements supported by query help files, see [Query help files](https://codeql.github.com/docs/writing-codeql-queries/query-help-files/) on codeql.github.com.
 
 
 ## English style
 
 You should write the overview and recommendation elements in simple English that is easy to follow. You should:
 
-*   Use simple sentence structures and avoid complex or academic language.
-*   Avoid colloquialisms and contractions.
-*   Use US English spelling throughout.
-*   Use words that are in common usage.
+* Use simple sentence structures and avoid complex or academic language.
+* Avoid colloquialisms and contractions.
+* Use US English spelling throughout.
+* Use words that are in common usage.
 
 ## Code examples
 
 Whenever possible, you should include a code example that helps to explain the issue you are highlighting. Any code examples that you include should adhere to the following guidelines:
 
-*   The example should be less than 20 lines, but it should still clearly illustrate the issue that the query identifies.  If appropriate, then the example may also be runnable.
-*   Put the code example after the recommendation element where possible. Only include an example in the description element if absolutely necessary.
-*   If you are using an example to illustrate the solution to a problem, and the change required is minor, avoid repeating the whole example. It is preferable to either describe the change required or to include a smaller snippet of the corrected code.
-*   Clearly indicate which of the samples is an example of bad coding practice and which is recommended practice.
-*   Define the code examples in `src` files. The language is inferred from the file extension:
+* The example should be less than 20 lines, but it should still clearly illustrate the issue that the query identifies.  If appropriate, then the example may also be runnable.
+* Put the code example after the recommendation element where possible. Only include an example in the description element if absolutely necessary.
+* If you are using an example to illustrate the solution to a problem, and the change required is minor, avoid repeating the whole example. It is preferable to either describe the change required or to include a smaller snippet of the corrected code.
+* Clearly indicate which of the samples is an example of bad coding practice and which is recommended practice.
+* Define the code examples in `src` files. The language is inferred from the file extension:
 
-```
-<example>
-<p>This example highlights poor coding practice</p>
+  ```xml
+  <example>
+  <p>This example highlights poor coding practice</p>
 
-<sample src = "example-code-bad.java" />
+  <sample src = "example-code-bad.java" />
 
-<p>This example shows how to fix the code</p>
+  <p>This example shows how to fix the code</p>
 
-<sample src = "example-code-fixed.java" />
-</example>
-```
+  <sample src = "example-code-fixed.java" />
+  </example>
+  ```
 
 Note, if any code words are included in the `overview` and `recommendation` sections, they should be formatted with `<code> ... </code>` for emphasis.
 
@@ -90,7 +91,7 @@ Note, & symbols need to be replaced by \&amp;. The symbol will be displayed corr
 
 ### Academic papers
 
-If you are citing an academic paper, we recommend adopting the reference style of the journal that you are citing. For example: 
+If you are citing an academic paper, we recommend adopting the reference style of the journal that you are citing. For example:
 
 >S. R. Chidamber and C. F. Kemerer, _A metrics suite for object-oriented design_. IEEE Transactions on Software Engineering, 20(6):476-493, 1994.
 
@@ -109,11 +110,11 @@ For example:
 
 If your query checks code for a CWE weakness, you should use the `@tags` element in the query file to reference the associated CWEs, as explained [here](query-metadata-style-guide.md). When you use these tags, a link to the appropriate entry from the [MITRE.org](https://cwe.mitre.org/scoring/index.html) site will automatically appear as a reference in the output HTML file.
 
-## Query help example 
+## Query help example
 
-The following example is a query help file for a query from the standard query suite for Java: 
+The following example is a query help file for a query from the standard query suite for Java:
 
-```
+```xml
 <!DOCTYPE qhelp PUBLIC
   "-//Semmle//qhelp//EN"
   "qhelp.dtd">