Policies » Historie » Verze 21
Jan Pašek, 2021-03-03 17:05
1 | 3 | Jan Pašek | h1. Project convention |
---|---|---|---|
2 | 1 | Jan Pašek | |
3 | h2. Git |
||
4 | 6 | Jan Pašek | |
5 | 13 | Jan Pašek | *Commits* |
6 | |||
7 | 12 | Jan Pašek | Commit message shall have the following format: |
8 | <pre> |
||
9 | #<id> - <short description> <details> |
||
10 | </pre> |
||
11 | |||
12 | * *id* issue ID from the Redmine |
||
13 | * *short description* brief description of the change |
||
14 | * *details* detailed list of changes (added classes, changed interfaces, ...) |
||
15 | 13 | Jan Pašek | |
16 | Each commit shall have a reasonable size to make the reviews as simple as possible. |
||
17 | |||
18 | *Branches* |
||
19 | |||
20 | 20 | Jan Pašek | The name of the branch shall follow the following format: |
21 | |||
22 | <pre> |
||
23 | #<id>_<description> |
||
24 | </pre> |
||
25 | |||
26 | 21 | Jan Pašek | * *id* RedMine issue ID |
27 | * *description* short description of the change based issue name - without special characters, words separated by underscores |
||
28 | 20 | Jan Pašek | |
29 | # For each issue, a new branch shall be created. |
||
30 | 13 | Jan Pašek | # When the work on a branch is finished by the *issue owner*, the work is posted for a code review. |
31 | # After that, the code can be merged to master by the *reviewer*. |
||
32 | # After the merge, the *reviewer* is responsible for verifying software integrity. |
||
33 | 14 | Jan Pašek | # _In case the integrity of the software is seriously broken, the task can be returned to the *issue owner*._ |
34 | |||
35 | *Code review* |
||
36 | |||
37 | * Reviewer walks through the code and checks the coding convention, code readability, stability, etc... |
||
38 | * Reviewer is responsible for basic functionality testing |
||
39 | 17 | Jan Pašek | * Code review is tracked in GitLab via merge request |
40 | 11 | Jan Pašek | |
41 | 1 | Jan Pašek | h2. RedMine |
42 | 2 | Jan Pašek | |
43 | 16 | Jan Pašek | * Everyone can create an issue |
44 | * New issues must have the following fields filled in: Type, Title, Description, State = Normal |
||
45 | 19 | Jan Pašek | * Optionally one can set parent issue or watchers |
46 | * One has to update the spent time periodically |
||
47 | |||
48 | +Description:+ |
||
49 | * Administrative: What has to be done, possible Wiki page references, what are the work products (where to store them - eg. in DMS), what shall the work products contain |
||
50 | * Functional: Description of the change, possible references to the requirement |
||
51 | |||
52 | 16 | Jan Pašek | |
53 | 4 | Jan Pašek | h2. Code |
54 | 5 | Jan Pašek | |
55 | h3. General |
||
56 | |||
57 | * Code and all comments shall be written in English |
||
58 | 9 | Jan Pašek | * Code review is done for all code changes |
59 | * Unit tests are done for all business logic parts |
||
60 | 5 | Jan Pašek | * Python docstrings (bellow function header) shall be created for all functions describing the purpose, inputs and outputs |
61 | * Avoid using names that are too general or too wordy. Strike a good balance between the two |
||
62 | * When using CamelCase names, capitalize all letters of an abbreviation (e.g. HTTPServer) |
||
63 | |||
64 | h3. Packages |
||
65 | |||
66 | * Package names should be all lower case |
||
67 | * When multiple words are needed, an underscore should separate them |
||
68 | * It is usually preferable to stick to 1-word names |
||
69 | |||
70 | h3. Modules |
||
71 | |||
72 | * Module names should be all lower case |
||
73 | * When multiple words are needed, an underscore should separate them |
||
74 | * It is usually preferable to stick to 1 word names |
||
75 | |||
76 | h3. Classes |
||
77 | |||
78 | * Class names should follow the UpperCaseCamelCase convention |
||
79 | * Exception classes should end in “Error” |
||
80 | |||
81 | h3. Global Variables |
||
82 | |||
83 | * Global variables should be all lowercase |
||
84 | * Words in a global variable name should be separated by an underscore |
||
85 | |||
86 | h3. Instance Variables |
||
87 | |||
88 | * Instance variable names should be all lower case |
||
89 | * Words in an instance variable name should be separated by an underscore |
||
90 | 10 | Jan Pašek | * Non-public instance variables should begin with a double underscore |
91 | * If a protected attribute is necessary to be used, the variable name shall start with a single underscore |
||
92 | 5 | Jan Pašek | * If an instance name needs to be mangled (interpreter rewrites the name in order to avoid name conflicts in subclasses), two underscores may begin its name |
93 | |||
94 | h3. Methods |
||
95 | |||
96 | * Method names should be all lower case |
||
97 | * Words in a method name should be separated by an underscore |
||
98 | * Non-public method should begin with a single underscore |
||
99 | * If a method name needs to be mangled, two underscores may begin its name |
||
100 | |||
101 | h3. Method Arguments |
||
102 | |||
103 | * Instance methods should have their first argument named ‘self’. |
||
104 | * Class methods should have their first argument named ‘cls’ |
||
105 | |||
106 | h3. Functions |
||
107 | |||
108 | * Function names should be all lower case |
||
109 | * Words in a function name should be separated by an underscore |
||
110 | |||
111 | h3. Constants |
||
112 | |||
113 | * Constant names must be fully capitalized |
||
114 | * Words in a constant name should be separated by an underscore |