Skip to content

Commit 843c5c6

Browse files
authored
Merge pull request github#3742 from jf205/sd-110
CodeQL docs: Expand QLDoc style guide
2 parents 3747bd9 + 7e7d7e7 commit 843c5c6

File tree

2 files changed

+185
-73
lines changed

2 files changed

+185
-73
lines changed

docs/ql-style-guide.md

Lines changed: 1 addition & 73 deletions
Original file line numberDiff line numberDiff line change
@@ -214,79 +214,7 @@ class Type extends ... {
214214

215215
## Documentation
216216

217-
General requirements:
218-
219-
1. Documentation *must* adhere to the [QLDoc specification](https://help.semmle.com/QL/ql-handbook/qldoc.html).
220-
1. Use `/** ... */` for documentation, even for single line comments.
221-
1. For single-line documentation, the `/**` and `*/` are written on the same line as the comment.
222-
1. For multi-line documentation, the `/**` and `*/` are written on separate lines. There is a `*` preceding each comment line, aligned on the first `*`.
223-
1. Use full sentences, with capital letters and full stops.
224-
1. Use American English.
225-
1. Documentation comments *should* be appropriate for users of the code.
226-
1. Documentation for maintainers of the code *must* use normal comments.
227-
228-
Documentation for specific items:
229-
230-
1. Public declarations *must* be documented.
231-
1. Non-public declarations *should* be documented.
232-
1. Declarations in query files *should* be documented.
233-
1. Library files (`.qll` files) *should* be have a documentation comment at the top of the file.
234-
1. Query files, except for tests, *must* have a QLDoc query documentation comment at the top of the file.
235-
1. Predicates that do not have a result *should* be documented `/** Holds if ... */`
236-
1. Predicates that have a result *should* be documented `/** Gets ... */`
237-
1. All predicate parameters *should* be referred to in the predicate documentation.
238-
1. Reference names, such as types and parameters, using backticks `` ` ``.
239-
1. Give examples of code in the target language, enclosed in ```` ``` ```` or `` ` ``.
240-
1. Classes *should* be documented in the singular, for example `/* An expression. */`
241-
1. Where a class denotes a generic concept with subclasses, list those subclasses.
242-
1. Declarations that are deprecated *should* be documented as `DEPRECATED: ...`
243-
1. Declarations that are for internal use *should* be documented as `INTERNAL: Do not use`.
244-
245-
### Examples
246-
247-
```ql
248-
/** Provides logic for determining constant expressions. */
249-
```
250-
251-
```ql
252-
/**
253-
* Holds if the qualifier of this call has type `qualifierType`.
254-
* `isExactType` indicates whether the type is exact, that is, whether
255-
* the qualifier is guaranteed not to be a subtype of `qualifierType`.
256-
*/
257-
```
258-
```ql
259-
/**
260-
* A delegate declaration, for example
261-
* ```
262-
* delegate void Logger(string text);
263-
* ```
264-
*/
265-
class Delegate extends ...
266-
```
267-
268-
```ql
269-
/**
270-
* An element that can be called.
271-
*
272-
* Either a method (`Method`), a constructor (`Constructor`), a destructor
273-
* (`Destructor`), an operator (`Operator`), an accessor (`Accessor`),
274-
* an anonymous function (`AnonymousFunctionExpr`), or a local function
275-
* (`LocalFunction`).
276-
*/
277-
class Callable extends ...
278-
```
279-
280-
```ql
281-
/** DEPRECATED: Use `getAnExpr()` instead. */
282-
deprecated Expr getInitializer()
283-
```
284-
285-
```ql
286-
/**
287-
* INTERNAL: Do not use.
288-
*/
289-
```
217+
For more information about documenting the code that you contribute to this repository, see the [QLDoc style guide](qldoc-style-guide.md).
290218

291219
## Formulas
292220
1. *Prefer* one *conjunct* per line.

docs/qldoc-style-guide.md

Lines changed: 184 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,184 @@
1+
# QLDoc style guide
2+
3+
## Introduction
4+
5+
Valid QL comments are known as QLDoc. This document describes the recommended styles and conventions you should use when writing QLDoc for code contributions in this repository. If there is a conflict between any of the recommendations in this guide and clarity, then clarity should take precedence.
6+
7+
### General requirements
8+
9+
1. Documentation must adhere to the [QLDoc specification](https://help.semmle.com/QL/ql-handbook/qldoc.html).
10+
1. Documentation comments should be appropriate for users of the code.
11+
1. Documentation for maintainers of the code must use normal comments.
12+
1. Use `/** ... */` for documentation, even for single line comments.
13+
- For single-line documentation, the `/**` and `*/` are written on the same line as the comment.
14+
- For multi-line documentation, the `/**` and `*/` are written on separate lines. There is a `*` preceding each comment line, aligned on the first `*`.
15+
1. Use code formatting (backticks) within comments for code from the source language, and also for QL code (for example, names of classes, predicates, and variables).
16+
1. Give explanatory examples of code in the target language, enclosed in ```` ``` ```` or `` ` ``.
17+
18+
19+
### Language requirements
20+
21+
1. Use American English.
22+
1. Use full sentences, with capital letters and periods, except for the initial sentence of the comment, which may be fragmentary as described below.
23+
1. Use simple sentence structures and avoid complex or academic language.
24+
1. Avoid colloquialisms and contractions.
25+
1. Use words that are in common usage.
26+
27+
28+
### Requirements for specific items
29+
30+
1. Public declarations must be documented.
31+
1. Non-public declarations should be documented.
32+
1. Declarations in query files should be documented.
33+
1. Library files (`.qll` files) should be have a documentation comment at the top of the file.
34+
1. Query files, except for tests, must have a QLDoc query documentation comment at the top of the file.
35+
36+
## QLDoc for predicates
37+
38+
1. Refer to all predicate parameters in the predicate documentation.
39+
1. Reference names, such as types and parameters, using backticks `` ` ``.
40+
1. Give examples of code in the target language, enclosed in ```` ``` ```` or `` ` ``.
41+
1. Predicates that override a single predicate don't need QLDoc, as they will inherit it.
42+
43+
### Predicates without result
44+
45+
1. Use a third-person verb phrase of the form ``Holds if `arg` has <property>.``
46+
1. Avoid:
47+
- `/** Whether ... */`
48+
- `/**" Relates ... */`
49+
- Question forms:
50+
- ``/** Is `x` a foo? */``
51+
- ``/** Does `x` have a bar? */``
52+
53+
#### Example
54+
55+
```ql
56+
/**
57+
* Holds if the qualifier of this call has type `qualifierType`.
58+
* `isExactType` indicates whether the type is exact, that is, whether
59+
* the qualifier is guaranteed not to be a subtype of `qualifierType`.
60+
*/
61+
```
62+
63+
### Predicates with result
64+
65+
1. Use a third-person verb phrase of the form `Gets (a|the) <thing>.`
66+
1. Use "if any" if the item is usually unique but might be missing. For example
67+
`Gets the body of this method, if any.`
68+
1. If the predicate has more complex behaviour, for example multiple arguments are conceptually "outputs", it can be described like a predicate without a result. For example
69+
``Holds if `result` is a child of this expression.``
70+
1. Avoid:
71+
- `Get a ...`
72+
- `The ...`
73+
- `Results in ...`
74+
- Any use of `return`
75+
76+
#### Example
77+
```ql
78+
/**
79+
* Gets the expression denoting the super class of this class,
80+
* or nothing if this is an interface or a class without an `extends` clause.
81+
*/
82+
```
83+
84+
### Deprecated predicates
85+
86+
The documentation for deprecated predicates should be updated to emphasize the deprecation and specify what predicate to use as an alternative.
87+
Insert a sentence of the form `DEPRECATED: Use <other predicate> instead.` at the start of the QLDoc comment.
88+
89+
#### Example
90+
91+
```ql
92+
/** DEPRECATED: Use `getAnExpr()` instead. */
93+
deprecated Expr getInitializer()
94+
```
95+
96+
### Internal predicates
97+
98+
Some predicates are internal-only declarations that cannot be made private. The documentation for internal predicates should begin with `INTERNAL: Do not use.`
99+
100+
#### Example
101+
102+
```ql
103+
/**
104+
* INTERNAL: Do not use.
105+
*/
106+
```
107+
108+
### Special predicates
109+
110+
Certain special predicates should be documented consistently.
111+
112+
- Always document `toString` as
113+
114+
```ql
115+
/** Gets a textual representation of this element. */
116+
string toString() { ... }
117+
```
118+
119+
- Always document `hasLocationInfo` as
120+
121+
```ql
122+
/**
123+
* Holds if this element is at the specified location.
124+
* The location spans column `startcolumn` of line `startline` to
125+
* column `endcolumn` of line `endline` in file `filepath`.
126+
* For more information, see
127+
* [Locations](https://help.semmle.com/QL/learn-ql/locations.html).
128+
*/
129+
130+
predicate hasLocationInfo(string filepath, int startline, int startcolumn, int endline, int endcolumn) { ... }
131+
```
132+
## QLDoc for classes
133+
134+
1. Document classes using a noun phrase of the form `A <domain element> that <has property>.`
135+
1. Use "that", not "which".
136+
1. Refer to member elements in the singular.
137+
1. Where a class denotes a generic concept with subclasses, list those subclasses.
138+
139+
#### Example
140+
141+
```ql
142+
/**
143+
* A delegate declaration, for example
144+
* ```
145+
* delegate void Logger(string text);
146+
* ```
147+
*/
148+
class Delegate extends ...
149+
```
150+
151+
```ql
152+
/**
153+
* An element that can be called.
154+
*
155+
* Either a method (`Method`), a constructor (`Constructor`), a destructor
156+
* (`Destructor`), an operator (`Operator`), an accessor (`Accessor`),
157+
* an anonymous function (`AnonymousFunctionExpr`), or a local function
158+
* (`LocalFunction`).
159+
*/
160+
class Callable extends ...
161+
```
162+
163+
## QLDoc for modules
164+
165+
Modules should be documented using a third-person verb phrase of the form `Provides <classes and predicates to do something>.`
166+
167+
#### Example
168+
169+
```ql
170+
/** Provides logic for determining constant expressions. */
171+
```
172+
```ql
173+
/** Provides classes representing the control flow graph within functions. */
174+
```
175+
176+
## Special variables
177+
178+
When referring to `this`, you may either refer to it as `` `this` `` or `this <type>`. For example:
179+
- ``Holds if `this` is static.``
180+
- `Holds if this method is static.`
181+
182+
When referring to `result`, you may either refer to it as `` `result` `` or as `the result`. For example:
183+
- ``Holds if `result` is a child of this expression.``
184+
- `Holds if the result is a child of this expression.`

0 commit comments

Comments
 (0)