-
Notifications
You must be signed in to change notification settings - Fork 2
/
HACKING
59 lines (46 loc) · 2.93 KB
/
HACKING
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
This project generally takes inspiration from the Linux kernel in terms of how the development
process is structured. In particular, the following guide is broadly applicable:
https://www.kernel.org/doc/html/latest/process/submitting-patches.html
All commits are expected to follow the above guidelines. In particular, commits are expected to be
in the following format:
Add frobnicator to fizzbuzz page
This is an extended description outlining the major changes found in the
patch. It consists of multiple sentences and covers the substance of the
commit, as well as the reasoning behind the commit. If there are any
nonintuitive parts to the implementation, they are described here.
Alternative paths not taken are also discussed. This description is wrapped
at 75 characters.
Closes: #999
Signed-off-by: J. Random Developer <[email protected]>
Unlike Linux, we accept GitHub PRs. All code is expected to be ready to be cherry-picked onto
master as-is. In particular, merge commits and incremental updates are not allowed. Rebase your
commits if I update master, and squash your fixes if you need to make changes.
The following style guidelines apply to all code:
- Function and variable names should be written in snake_case. Class names should be written in
CamelCase.
- Indentation should be done with (8-space) tabs and not spaces. It is acceptable to use spaces for
alignment purposes. Python code uses 4 spaces for indentation.
- Only one blank (empty) line may occur in a row.
- Lines should be wrapped at 100 columns. If there is a significant readability gain, lines may be
wrapped at 110 columns.
- All files must have a trailing newline.
- When expressions are broken across multiple lines, the operator should be at the beginning of the
following lines.
- There should be one space between binary operators and their arguments. There should be no spaces
between the inside of parentheses and their contents.
The following guidelines apply to HTML:
- Inline CSS should be avoided wherever possible.
- Blocks may be left unindented to avoid excessive indentation
The following guidelines apply to SQL:
- SQL embedded in python may be enclosed in double quotes if it is only one line. Othewise, it
should be enclosed in triple double quotes (""").
- All statements should end in a semicolon.
- Additional clauses should be indented to match the opening statement, and result columns should be
indented an additional time.
- AS must be used when renaming tables or columns
- Wherever possible, USING should be used when joining tables.
- Opening and closing parentheses should not be on their own line.
- JOINs should not be prefixed with unnecessary qualifiers such as "FULL OUTER".
Modifications to the above style guidelines may be submitted. Such modifications should update this
document, and change all code to comply with the new guideline. If you find code which does not
adhere to the above guidelines, please submit a patch to fix it.