- Daniel Arbuckle's Mastering Python
- Daniel Arbuckle
- 340字
- 2021-07-02 21:09:41
Formatting recommendations
The code in the following screenshot demonstrates almost all the PEP 8 formatting recommendations:
I'll now walk us through the recommendations one by one:
- PEP 8 recommends that a single line of code should not exceed a width of 79 characters
While this is consistent with displaying the code on a standard text mode interface, the primary reason for this rule in the modern world of widescreens and resizable windows is that it helps with reading. Even in contexts that have nothing to do with programming, layout designers prefer to limit line width.
- Import statements should be placed at the top of the file, with standard library imports first, third-party imports next, and then imports from other modules within the same project
- There should be a blank line between each group of imports
- Classes and functions at the top level should have two blank lines separating them.
- Methods within a class should have one blank line separating them
- Within a function or method, blank lines should be used to indicate separation between conceptual groupings of code
- Don't insert extra spaces before or after parentheses, brackets, or braces; and don't insert spaces before commas or colons
- Always put a single space on either side of a binary operator, such as + or /
- Don't put more than one statement on the same line, which is occasionally possible, but never a good idea
- Comments should be written in human language, using that language's correct grammar
Preferably, that language should be English if you're going to allow your source code into the wild because this language is common to the majority of Python programmers.
- Comments should also precede the section of code they described and be indented to the same level
- Every public module, class, function, or method should have a properly formatted docstring
We'll look at what properly formatted means for docstrings in the Getting the most out of docstrings section of this chapter.
Let's move on to picking names for variables, functions, methods, classes, modules, packages, and so on.