Python code specifications

1: Background

is used to standardize ocp python development, and use a unified style for programs developed using python to facilitate code Maintenance

Two:pythonStyle specification

• points Symbol: Do not add a semicolon at the end of the line, and do not use a semicolon to put two commands on the same line

• Brackets: Use brackets sparingly rather than excessively. Unless used to implement row concatenation, do not use parentheses in return statements or conditional statements, but parentheses around tuples are allowed

• Indentation: use 4 spaces. Instead of indenting code. Never use tabs, or mix tabs and spaces. For line concatenation, you should either vertically align wrapped elements, or use a 4-space hanging indent (in which case there should be no parameters on the first line)

• Empty line :Two empty lines between top-level definitions, such as functionor class definitions. There should be a blank line between method definition, class definition and the first method. In functions or methods, if you think it is appropriate, leave a blank line in some places.

• Spaces: Use spaces on both sides of punctuation according to standard formatting conventions. There should be no spaces within the brackets; do not add spaces before commas, semicolons, and colons, but they should be added after them (except at the end of the line); there should be no spaces in the left parenthesis of parameter lists, index, or slices ;Add a space on both sides of the binary operator, such as assignment (=), comparison (==, <, >, !=, <>, <=, > =, in, not in, is, is not), Boolean (and, or, not). As for how to use the spaces on both sides of the arithmetic operators, you need to make your own judgment. However, both sides must be consistent; when '=' is used to indicate keyword parameters or default parameter values, do not use spaces on both sides of it; do not use spaces to vertically align tags between multiple lines, because this will become a maintenance problem Burden (applicable to:, #, =, etc.)

• Class: If a class does not inherit from other classes, it will be displayed from object classInheritance

• String : Even if the parameters are all strings, use the % operator or format method to format characters String , do not use the + method

• Import method: Each import has its own line. Imports should always be placed at the top of the file, after module comments and docstrings, and before module global variables and constants . Imports should be in order from most common to least commonGroup: standard library import; third-party library import;applicationprogram specified import, each group should be based on the completeness of each module Package paths are sorted lexicographically, ignoring case

• statements: Normally each statement should be on its own line. If the test results and test statements fit on one line, you can put them on the same line. In the case of a if statement, this can only be done if there is no else. In particular, never do this with try/except because try and except cannot be 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 will be added later

Three: Requirements:

• After the code is modified, you must first run pylint and then initiate a review. The pylint running score must be controlled above 90. Some obvious irregularities must be corrected

• pylint Usage: Execute tools/pylint.sh in the obztools directory file

## Four: Reference:

• PEP 8 – Style Guide for Python Code: http://legacy.python.org/dev/peps/pep-0008/

• Python Coding Style Guide Chinese translation (Google SOC): http://www.elias.cn/Python/PythonStyleGuide?from= Develop.PythonStyleGuide

The above is the detailed content of Python code specifications. For more information, please follow other related articles on the PHP Chinese website!