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