Projekt

Obecné

Profil

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