Python's minimalist coding specification

Objective

This article is to read the "Python Coding Rule" summarizes the most elite and simple coding specifications, according to each person's preferences, some places will have different choices, I just do the most simple and easy choice for their own, for your reference only.

Important Principles

1. It's important to maintain style consistency, but most importantly: know when to disagree
2. Two good reasons to break an established rule:
   • When applying rules can cause code readability to be degraded (readability is high)
   • Break the rules in order to be consistent with the surrounding code (history left over)

Minimalist specification

1. Use only spaces to indent
2. Using UTF-8 encoding
3. Write only one statement per line
4. Collapse long lines with the end of line backslash to limit the maximum of 79 characters per line
5. Import Package: Unique, large to small, absolute path per line
6. In-class methods are separated by 1 lines, 2 lines of outer space are separated
7. operator except *, empty 1 squares on both sides, function parameter = no space around
8. Other modules, functions, methods, and variables use all lowercase + underscores except the class name using the Hump method
9. 1 leading underscores are semi-public, 2 leading underscores are private, and a single, post-underline is used to differentiate from reserved words
10. Use Chinese comments during development, and then write English documents when publishing

Detailed specification full-text Universal

1. Use only spaces to indent, 4 spaces to represent 1 indent levels
2. The length of each line is limited to 79 characters, and a long line is collapsed using the end of line backslash
3. Using UTF-8 encoding
4. Write only one statement per line

Code naming

1. Import only one package in a row, in the order of imports: standard library, related main package, specific application, 1 rows of blank rows between each set of imports, all imports using the absolute path of the package
2. The definition of the split top function and class uses 2 lines blank, the method definition within the split class uses 1 lines, and the class row and the first method definition have 1 lines of blank lines
3. The whole use of English writing method to use a space, that is, only the comma, semicolon after the addition of 1 spaces, and any other symbols such as parentheses, brackets, curly braces and so on without spaces to separate symbols and characters, written together to represent a whole; operators are separated by 1 spaces on each side of the symbol except the * number; function parameter = No spaces around the number
4. Module Name: No underscore, short, all lowercase, class name, exception name: The Hump method of the first capitalized word string; function name, global variable name, method name, instance variable: All lowercase, underlined for readability; a leading underscore is used only for global variables that you do not want to import (there are also intrinsic functions and classes) with an underscore), Internal methods and instance variables that do not intend to be the public interface of the class, two leading underscores to represent the class's private name, and only to avoid name collisions with the properties in the class (designed for subclasses)
5. The private attribute must have two leading underscores, no trailing underlines, and non-public attributes must have a leading underscore, no trailing underline. Public properties do not have leading and trailing underscores, unless they conflict with reserved words, in which case a single, post-underline is better than a pre-or chaotic spelling, for example: Class_ is better than Klass.

Writing skills

1. Compared to a single value like None, always use: ' Is ' or ' is not ' to do:if x is not None
2. Defining base exception classes within modules and packages (Base exception Class)
3. Use a String method (methods) instead of a string module
4. Avoid slicing strings when checking prefixes or suffixes, using startswith () and EndsWith () instead, such as: No: if foo[:3] == ‘bar‘: Yes:if foo.startswith(‘bar‘):
5. Use only Isinstance () for object type comparisons, such as: No: if type(obj) is type(1): Yes:if isinstance(obj, int)
6. Determine true or false do not use = =, such as: No: if greeting == True: Yes:if greeting:

Comments

1. When developing, comments are all written in Chinese, and when you want to publish the script tool, write the English document
2. The comment should be a complete sentence (the phrase can also), the first letter capitalized, if the comment is short, omit the end of the period, the comment block consists of one or more complete sentences consisting of a paragraph, each sentence using the end of sentence; use two spaces after the end of the sentence
3. The comment block starts with # and a space, and the code that follows the comment has the same indentation level, and a blank line is enclosed below the comment block
4. Use inline comments sparingly, using at least two spaces to separate statements
5. Use Pydoc; Epydoc; Document strings for all public modules, functions, classes, and methods, such as Doxgen, are not necessary for non-public methods, but you should have a comment that describes what this method does, and this comment should be in the "Def" line
6. "" "At the end of a multi-line document string should be separate rows
7. Version annotation: Defining a variable__version__ = "$Revision: 1.4 $"

Python's minimalist coding specification