Python code specification and python code
I. background
It is used to standardize ocp python development. It adopts a uniform style for programs developed using python to facilitate code maintenance.
II:PythonStyle specifications
- Semicolon: do not add points at the end of a line, or use a semicolon to place the two commands on the same line.
- Brackets: You should rather use brackets. Do not use parentheses in the return statement or condition statement unless it is used to implement row join, but use parentheses on both sides of the tuples is allowed.
- Indent: four spaces are used to replace the indent code. Do not use tabs, or mix tabs and spaces. In the case of row connection, you should either vertically align the elements of the line feed or use a 4-space suspension indent (at this time, the first line should not have a parameter)
- Empty rows: There are two empty rows between top-level definitions, such as functions or class definitions. Method definition. A row should be empty between the class definition and the first method. In a function or method, if you think it is appropriate, leave a row empty.
- Space: Use spaces on both sides of the punctuation according to standard typographical specifications. Do not add spaces in parentheses; do not add spaces at the front of commas, semicolons, and colons, but add spaces behind them (except at the end of the line ); the parameter list, index, or slice should not contain spaces in the left brackets. A space should be added on both sides of the binary operator, such as a value assignment (=), comparison (=, <,> ,! =, <>,<=, >=, In, not in, is, is not), Boolean (and, or, not ). As for how to use spaces on both sides of an arithmetic operator, you need to make a good decision. However, make sure that the two sides are consistent. When '=' is used to indicate the keyword parameter or default parameter value, do not use spaces on both sides. Do not use spaces to vertically mark the multiple rows, because this will become a burden of maintenance (applicable to:, #, =, etc)
- Class: If a class does not inherit from other classes, the displayed class inherits from the object class.
- String: If all parameters are strings, use the % operator or format to format the string. Do not use the + method.
- Import method: 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 global variables and constants of the module. Import should be grouped according to the sequence from the most common to the least General: Standard Library import; third-party library import; the application specifies the import, each group should be sorted alphabetically by the complete package path of each module, regardless of Case sensitivity.
- Statement: Generally, each statement must have an exclusive row. If the test results and test statements are placed in one row, you can also put them in one row. If it is an if statement, this can be done only when there is no else. In particular, do not do this for try/try t, because try and try t cannot be placed in the same row.
- Name: ob_module_name ob_package_name ObClassName TestObClassName method_name test_method_name predictionname function_name GLOBAL_VAR_NAME instance_var_name function_parameter_name local_var_name
- Other points to be supplemented later
Iii. Requirements:
- After the code is modified, you must first run pylint and then initiate review. The pylint running score must be controlled above 90, and some obvious irregularities must be corrected.
- Pylint usage: Execute tools/pylint. sh file in the obztools directory
Iv. Reference:
- PEP 8-Style Guide for Python Code: click here
- Google SOC: click here
