Policies » Historie » Verze 12
Jan Pašek, 2021-03-03 16:26
| 1 | 3 | Jan Pašek | h1. Project convention |
|---|---|---|---|
| 2 | 1 | Jan Pašek | |
| 3 | h2. Git |
||
| 4 | 6 | Jan Pašek | |
| 5 | 12 | Jan Pašek | Commit message shall have the following format: |
| 6 | <pre> |
||
| 7 | #<id> - <short description> <details> |
||
| 8 | </pre> |
||
| 9 | |||
| 10 | * *id* issue ID from the Redmine |
||
| 11 | * *short description* brief description of the change |
||
| 12 | * *details* detailed list of changes (added classes, changed interfaces, ...) |
||
| 13 | 11 | Jan Pašek | |
| 14 | 1 | Jan Pašek | h2. RedMine |
| 15 | 2 | Jan Pašek | |
| 16 | 4 | Jan Pašek | h2. Code |
| 17 | 5 | Jan Pašek | |
| 18 | h3. General |
||
| 19 | |||
| 20 | * Code and all comments shall be written in English |
||
| 21 | 9 | Jan Pašek | * Code review is done for all code changes |
| 22 | * Unit tests are done for all business logic parts |
||
| 23 | 5 | Jan Pašek | * Python docstrings (bellow function header) shall be created for all functions describing the purpose, inputs and outputs |
| 24 | * Avoid using names that are too general or too wordy. Strike a good balance between the two |
||
| 25 | * When using CamelCase names, capitalize all letters of an abbreviation (e.g. HTTPServer) |
||
| 26 | |||
| 27 | h3. Packages |
||
| 28 | |||
| 29 | * Package names should be all lower case |
||
| 30 | * When multiple words are needed, an underscore should separate them |
||
| 31 | * It is usually preferable to stick to 1-word names |
||
| 32 | |||
| 33 | h3. Modules |
||
| 34 | |||
| 35 | * Module names should be all lower case |
||
| 36 | * When multiple words are needed, an underscore should separate them |
||
| 37 | * It is usually preferable to stick to 1 word names |
||
| 38 | |||
| 39 | h3. Classes |
||
| 40 | |||
| 41 | * Class names should follow the UpperCaseCamelCase convention |
||
| 42 | * Exception classes should end in “Error” |
||
| 43 | |||
| 44 | h3. Global Variables |
||
| 45 | |||
| 46 | * Global variables should be all lowercase |
||
| 47 | * Words in a global variable name should be separated by an underscore |
||
| 48 | |||
| 49 | h3. Instance Variables |
||
| 50 | |||
| 51 | * Instance variable names should be all lower case |
||
| 52 | * Words in an instance variable name should be separated by an underscore |
||
| 53 | 10 | Jan Pašek | * Non-public instance variables should begin with a double underscore |
| 54 | * If a protected attribute is necessary to be used, the variable name shall start with a single underscore |
||
| 55 | 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 |
| 56 | |||
| 57 | h3. Methods |
||
| 58 | |||
| 59 | * Method names should be all lower case |
||
| 60 | * Words in a method name should be separated by an underscore |
||
| 61 | * Non-public method should begin with a single underscore |
||
| 62 | * If a method name needs to be mangled, two underscores may begin its name |
||
| 63 | |||
| 64 | h3. Method Arguments |
||
| 65 | |||
| 66 | * Instance methods should have their first argument named ‘self’. |
||
| 67 | * Class methods should have their first argument named ‘cls’ |
||
| 68 | |||
| 69 | h3. Functions |
||
| 70 | |||
| 71 | * Function names should be all lower case |
||
| 72 | * Words in a function name should be separated by an underscore |
||
| 73 | |||
| 74 | h3. Constants |
||
| 75 | |||
| 76 | * Constant names must be fully capitalized |
||
| 77 | * Words in a constant name should be separated by an underscore |