0. Preface
This article is the most essential and simple coding standard summarized after reading "Python Coding Rule". According to everyone's different preferences, there will be different choices in some places. I just made the most simple and easy choice for myself, just for everyone refer to.
1. Important principles
a. It's important to keep style consistent, but most importantly: know when to be inconsistent
b. Two good reasons to break a given rule:
c. When applying the rule makes code less readable (readability races high )
d. Breaking the rules for consistency with surrounding code (legacy)
2. Minimal specification
a. Use only spaces for indentation
b. Use UTF-8 encoding
c. Write only one statement per line
d. Use end-of-line backslashes to fold long lines, limit each line to a maximum of 79 characters
e. Import packages: unique per line, from the largest To the small, absolute path
f. The method inside the class is separated by one empty line, and the space outside the class is separated by 2 lines.
g. Except for *, the two sides of the operator are separated by one space, and there is no space around the function parameter =
h. , other modules, functions, methods, and variables are all lowercase + underscore
i. 1 leading underscore means semi-public, 2 leading underscores mean private, and a single trailing underscore is used to distinguish it from reserved words
j. Use Chinese comments during development and release Write English documents when
3. Detailed specifications
a. The full text is general
b. Use only spaces for indentation, 4 spaces represent 1 indentation level
c. The length of each line is limited to 79 characters, use the backslash at the end of the line to fold long lines
d. Use UTF-8 encoding
e. Each write only one statement
4. Code naming
Only one package is imported per line. The order of Imports is: standard library, related main package, and specific application. A blank line is placed between each group of imports. All imports use the absolute path of the package.
Use 2 blank lines to separate top-level function and class definitions, 1 blank line to separate method definitions within a class, and 1 blank line between the class line and the first method definition.
Use English notation as a whole to use spaces, that is, only add a space after commas and semicolons, and any other symbols such as parentheses, square brackets, curly brackets, etc. do not use spaces to separate symbols from characters, and they are written together to represent a whole ; Operators except the * sign, are separated by a space on both sides of the other symbols; no spaces are used around the = sign for function parameters.
Module name: no underscore, short, all lowercase;
Class name, exception name: the camel case method of the first letter capitalized word string;
Function name, global variable name, method name, instance variable: all lowercase, underlined to increase readability;
A leading underscore is only used for global variables that are not intended to be imported (and internal functions and classes), internal methods and instance variables that are not intended to be the public interface of the class;
Two leading underscores are used to denote class-private names, and are only used to avoid name collisions with properties in the class (which is designed to be subclassable).
Private properties must have two leading underscores and no trailing underscores;
Non-public properties must have a leading underscore and no trailing underscore.
Public properties have no leading and trailing underscores, unless they conflict with reserved words, in which case a single trailing underscore is better than leading or messy spelling, eg: class_ is better than klass.
5. Writing skills
For single-value comparisons like None, always do it with: 'is' or 'is not': if x is not None
Define base exception classes within modules and packages
Use string methods instead of string modules.
Avoid slicing strings when checking for prefix or suffix, use startswith() and endswith() instead, like: No: if foo[:3] == 'bar':Yes: if foo.startswith('bar') :
Only use isinstance() to compare object types, such as: No: if type(obj) is type(1):Yes: if isinstance(obj, int)
Do not use == to judge True or False, such as: No: if greeting == True: Yes: if greeting:
6. Notes
During development, all comments are written in Chinese, and when scripting tools are to be released, English documents are written.
Comments should be complete sentences (phrases are also acceptable), with the first letter capitalized; if the comment is very short, omit the full stop at the end; the comment block consists of one or more complete sentence paragraphs, each sentence ends with a sentence; at the end of the sentence Use two spaces after the period.
Each line of a comment block begins with # and a space, and the code following the comment has the same indentation level, surrounded by a blank line above and below the comment block.
Use inline comments sparingly and separate statements with at least two spaces.
Use documentation tools like pydoc; epydoc; Doxgen to write docstrings for all public modules, functions, classes and methods. Docstrings are not necessary for non-public methods, but you should have a description of what the method does Comment, this comment should be after the "def" line.
The """ at the end of a multi-line docstring should be on a separate line.
Version note: define a variable __version__ = "$Revision: 1.4 $"
Stay hungry. Stay foolish.
Article link: https://www.cnblogs.com/Chayeen/p/8884776.html
This article is reproduced from [Big Data Daily Review]
Reply "1" in the official account to bring you into the fan group