I. PEP 8 specification
Official Documentation:/dev/peps/pep-0008/
Chinese translation:https:///article/
II. Indentation
Indent each level by 4 spaces.
Continuing lines should be aligned with wrapping elements, either vertically using round brackets, square brackets, or implicit line joins within curly braces, or aligned using hanging line indentation. When using hanging line indent alignment, one should take into account that the first line should not have parameters, as well as using indentation to distinguish itself as a continuation line.
- Aligned indentation (left and right bracket alignment)
def long_function_name(var_one, var_two, var_three, var_four): print(var_one)
- Suspension indent
def long_function_name( var_one, var_two, var_three, var_four): print(var_one)
- hierarchical indentation
def long_function_name( var_one, var_two, var_three, var_four): print(var_one, var_two, var_three, var_four)
III. Maximum length of rows
The maximum number of characters for all line limits is 79
Large chunks of text (document characters or comments) with no structured limitations are limited to a maximum of 72 characters per line.
with open("file1", "r") as f1, \ open("file2", "r") as f2: (())
IV. Blank lines
Top-level function and class definitions, separated by two blank lines before and after.
Method definitions inside a class are separated by a blank line.
class Class01: pass class Class02: def function_01(self): pass def function_02(self): pass
V. Naming conventions
variable naming
- Never use the letters I (lowercase L), O (uppercase O), and I (uppercase I) as single-character variable names.
- In some fonts, these characters cannot be distinguished from the numbers 0 and 1. If you want to use I, use L instead.
function naming
- Function names should be lowercase and can be separated by underscores if you want to improve readability.
- Case-mixing is only used in order to maintain backward compatibility with the original predominantly case-mixing style.
class naming
- Class names generally use the convention of initial capitalization.
- In cases where the interface is documented and is primarily used for calling, the naming style of the function can be used instead.
- Note: There is a separate convention for naming built-in variables: most built-in variables are single words (or two words joined together), and initial capitalization nomenclature is used only for exception names or internal constants.
Function and method parameters inside a class
- Always take self as the first argument to an instance method.
- Always take cls as the first argument to a class method.
- If a function's parameter name conflicts with an existing keyword, it's better to add an intentional underscore at the end than to abbreviate it or spell it randomly. Thus class_ is better than clss.
VI. String quotes
Single-quoted and double-quoted strings are the same.PEP will not give advice for this. Choose a rule and stick to it. When a string contains a single-quoted or double-quoted string, use a different symbol than the outermost to avoid backslashes, which improves readability.
Module and Package Import Specification
- Naming conventions Keep module names short, use lowercase, and avoid special symbols such as dots and question marks.
- So please try to keep the module name as simple as possible, so that there is no need to separate the words (the use of an underscore between two words is not recommended)
Module import recommendations
typical example | in the end |
from modu import * | Poorly, it is not clear what exactly is imported from the module. |
from modu import sqrt | slightly better |
import modu | It's best to use it directly when calling to know which module the current method belongs to. |
import os \n import sys |
testimonials |
import os, sys |
not recommended |
from subprocess import Popen, PIPE | as well |
__all__ variables
- If the global variable __all__ exists in the module, then importing it via __all__ from xxx import * will only import the methods and variables specified in __all__, but not all of them.
VII. Bags
- Any directory containing an __init__.py file is considered a python package.
- This is because the __init__.py file is executed first when importing packages
- The role of the __all__ variable in the __init__.py file in the package
- If there is a global variable __all__ in the file, importing it from xxx import * will only import the methods and variables specified in __all__, but not all of them.
VIII. Annotations
Comments that contradict the code are worse than no comments at all,When the code changes,Prioritize updating the corresponding annotations! Notes should be complete sentences。If an annotation is a phrase or sentence,Its first word should be capitalized,Unless it is an identifier that begins with a lowercase letter(Never change the case of an identifier!)。 If the comment is short,The period at the end can be omitted。Block annotations generally consist of one or more paragraphs of complete sentences,And there's a period at the end of each sentence.。 Two spaces should be used at the end of the sentence.。 In non-English-speaking countriespythonprogrammer,Please write your comments in English,only in the case that120%You can be sure that your code will not be read by people who use other languages.。
block note
Block comments are usually applied to some (or all) of the code that follows them, indented to the same level as the code. Block comments begin each line with a # and a space (unless the block comment indents the text internally).
Paragraphs inside a block comment are usually separated by only a # blank line.
in-line comment
Restrained use of in-line comments
An in-line comment is a comment that travels with the code statement. In-line comments and code should be separated by at least two spaces. A comment starts with # and a space.
documentation note
To write documentation for all public modules, functions, classes and methods.
Non-public methods are not necessary, but should have a comment describing exactly what the method does. This comment should come after the def line.
PEP257 describes the conventions associated with writing good documentation comments. Of particular note: the closing triple quote used for multi-line document comments should be on a line of its own, for example:
"""This is the annotation The specific inner cylinder of the note """
For a one-line document description,The trailing triple quote should be on the same line as the document。
to this article on the basics of python coding specification summarizes the article is introduced to this, more related python coding specification content please search for my previous articles or continue to browse the following related articles I hope you will support me in the future more!