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