One: Background
Used to standardize the development of the OCP Python, using a unified style for programs developed using Python for easy code maintenance
Two: python Style Specification
- Semicolon: Do not add a semicolon at the end of the line, and do not use a semicolon to place two commands on the same row
- Brackets: Use parentheses for Ningquewulan. Do not use parentheses in a return statement or conditional statement unless you are using it to implement a row connection, but using parentheses around the tuple is allowed
- Indent: Use 4 spaces instead of indentation code. Never use tab and do not mix tabs and spaces. For a row connection, you should either align the wrapped element vertically or use a 4-space dangling indent (at which point the first line should not have parameters)
- Blank line: Empty two rows between top-level definitions, such as functions or class definitions. method definition, the class definition and the first method should be empty lines. function or method, in some places, if you feel fit, empty line
- Spaces: Use the spaces on both sides of the punctuation according to the standard typographic specification. Do not have spaces in parentheses, do not precede commas, semicolons, and colons with spaces, but should be added behind them (except at the end of the line); The argument list, index, or the left parenthesis of the slice should not have spaces, add a space on either side of the two-dollar operator, such as assignment (=), and compare (= =, < <>, <=, >=, in, not in, was, is not), Boolean (and, or, not). As for how to use the space on either side of the arithmetic operator, you need to judge it yourself. However, it is important to keep the two sides consistent; do not use spaces on either side of a keyword parameter or default parameter value when ' = ' is used to indicate it; do not put spaces vertically to align multiple lines of markup, as this becomes a burden for maintenance (for:, #, =, etc.)
- Class: If a class does not inherit from another class, the object class that is displayed inherits from the
- String: If the argument is a string, use the% operator or format method to format the string, and do not use the + method
- Import by: Each import exclusive row. The import should always be placed at the top of the file, after the module comments and document strings, before the module global variables and constants. Imports should be grouped in the most general to least common order: standard library import, third-party library import, application-specific import, each grouping should be sorted in dictionary order according to the full package path of each module, ignoring case
- Statement: Typically each statement should have a single row. If the test results and test statements are placed on one line, you can also put them on one line. If this is an if statement, you can do so only if there is no else. In particular, never do this to try/except, because try and except cannot be placed on the same line.
- Name: Ob_module_name ob_package_name obclassname testobclassname method_name test_method_name ExceptionName function_ Name Global_var_name instance_var_name function_parameter_name local_var_name
- Other points to be added later
Three: Requirements:
- Code changes must first run Pylint and then launch Review,pylint run points to be controlled above 90, for some obvious irregularities must be corrected
- Pylint use: Execute tools/pylint.sh file in Obztools directory
Four: Reference:
- PEP 8–style Guide for Python Code: bash here
- Python Coding style Guide in translation (Google SOC): bash here
Python Code specification
