Python编程规范PEP8.pdf_PEP8编程规范资源-CSDN下载

需积分: 50 148 浏览量 2020-03-18 14:32:43 上传评论 2 收藏 164KB PDF 举报

Python编程规范PEP8是一个由Python社区广泛认可和遵循的编程风格指南。它的全称是“Style Guide for Python Code”，旨在提升Python代码的可读性和一致性。PEP8最初由Python的创始人Guido van Rossum、Barry Warsaw和Nick Coghlan共同撰写，并随着Python语言的发展不断更新。尽管它主要用于Python标准库的代码，但其影响力远超过标准库，被广泛应用于整个Python开发社区。 PEP8中详细规定了代码的格式化和排版规则，内容涵盖了空格、缩进、换行、注释、命名约定等方面。以下是一些PEP8中的核心知识点： 1. 命名规范：PEP8提倡使用有意义的变量名和函数名，尽可能清晰表达其代表的含义。它推荐使用小写字母和下划线来命名变量和函数（snake_case），避免使用单个字符的变量名，除非是在非常有限的范围内使用，例如迭代器中的计数器。 2. 注释规则：注释是代码的辅助说明，PEP8强调注释应该清晰、有用且保持更新。代码的每个函数或方法都应附有docstring（文档字符串），格式应遵循PEP257的规定。注释需要简洁、明确，避免冗长或含糊不清的描述。 3. 编程推荐：PEP8还推荐一些编程实践，如减少代码中的缩进层级，避免过长的行宽（建议不超过79字符），使用空格而非制表符（tab）进行缩进，以及在行尾保持空格的一致性等。这些推荐有助于提高代码的整体可读性和整洁性。 4. 代码布局：PEP8对代码的布局有明确的要求，包括文件、类和方法的结构，以及何时使用空行进行分隔。例如，一个文件应以解释器声明开始，紧接着是模块注释和文档字符串，然后是模块级别的变量和常量，最后是类和函数定义。 5. 避免复杂的语句和表达式：为了提高代码的可读性，PEP8建议避免使用复杂的语句，如复杂的条件表达式，应该使用简单的if-else结构。同时，尽量避免在表达式中使用多个逻辑运算符。 6. 兼容性：虽然PEP8是一个强大的代码风格指南，但它也指出了在特定情况下可以不完全遵循指南的情况。例如，如果遵循指南会降低代码的可读性，或者与项目内其他代码风格不一致，那么可以灵活调整。 7. 更新与变化：随着Python语言的持续发展，PEP8也在不断更新以适应新的编程实践和技术变化。这意味着开发者应该关注PEP8的最新版本，确保代码风格与当前Python社区的最佳实践保持一致。此外，PEP8还涵盖了具体的格式化工具的推荐，如使用pycodestyle、flake8等工具来检测代码是否符合PEP8指南，以及如何处理特殊情况，如处理遗留代码库时的指南冲突。 PEP8不仅是Python编程的风格指南，它也代表了Python社区对于代码质量、可读性和一致性的集体追求。对于Python开发者而言，遵循PEP8不仅有助于提高代码的质量，还有助于与其他Python开发者进行有效的沟通和协作。

资源推荐

资源详情

资源评论

PEP: 8 Title: Style Guide for Python Code Version: $Revision$ Last-Modified: $Date$ Author: Guido van

Rossum <[email protected]>,

Barry Warsaw <[email protected]>, Nick Coghlan <[email protected]>

Status: Active Type: Process Content-Type: text/x-rst Created: 05-Jul-2001 Post-History: 05-Jul-2001,

01-Aug-2013

Introduction

This document gives coding conventions for the Python code comprising the standard library in the main

Python distribution. Please see the companion informational PEP describing style guidelines for the C

code in the C implementation of Python

This document and PEP 257 (Docstring Conventions) were adapted from Guido's original Python Style

Guide essay, with some additions from Barry's style guide

This style guide evolves over time as additional conventions are identified and past conventions are

rendered obsolete by changes in the language itself.

Many projects have their own coding style guidelines. In the event of any conflicts, such project-specific

guides take precedence for that project.

A Foolish Consistency is the Hobgoblin of Little Minds

One of Guido's key insights is that code is read much more often than it is written. The guidelines provided

here are intended to improve the readability of code and make it consistent across the wide spectrum of

Python code. As PEP 20 says, "Readability counts".

A style guide is about consistency. Consistency with this style guide is important. Consistency within a

project is more important. Consistency within one module or function is the most important.

However, know when to be inconsistent -- sometimes style guide recommendations just aren't applicable.

When in doubt, use your best judgment. Look at other examples and decide what looks best. And don't

hesitate to ask!

In particular: do not break backwards compatibility just to comply with this PEP!

Some other good reasons to ignore a particular guideline:

1. When applying the guideline would make the code less readable, even for someone who is used to

reading code that follows this PEP.

2. To be consistent with surrounding code that also breaks it (maybe for historic reasons) -- although

this is also an opportunity to clean up someone else's mess (in true XP style).

3. Because the code in question predates the introduction of the guideline and there is no other reason

to be modifying that code.

4. When the code needs to remain compatible with older versions of Python that don't support the

feature recommended by the style guide.

Code Lay-out

Indentation

Use 4 spaces per indentation level.

Continuation lines should align wrapped elements either vertically using Python's implicit line joining inside

parentheses, brackets and braces, or using a hanging indent

. When using a hanging indent the following

View document source. Generated on: 2020-03-18 05:36 UTC. Generated by Docutils from reStructuredText

source.

should be considered; there should be no arguments on the first line and further indentation should be

used to clearly distinguish itself as a continuation line.

Yes:

# Aligned with opening delimiter.

foo = long_function_name(var_one, var_two,

var_three, var_four)

# Add 4 spaces (an extra level of indentation) to distinguish arguments from the rest.

def long_function_name(

var_one, var_two, var_three,

var_four):

print(var_one)

# Hanging indents should add a level.

foo = long_function_name(

var_one, var_two,

var_three, var_four)

No:

# Arguments on first line forbidden when not using vertical alignment.

foo = long_function_name(var_one, var_two,

var_three, var_four)

# Further indentation required as indentation is not distinguishable.

def long_function_name(

var_one, var_two, var_three,

var_four):

print(var_one)

The 4-space rule is optional for continuation lines.

Optional:

# Hanging indents *may* be indented to other than 4 spaces.

foo = long_function_name(

var_one, var_two,

var_three, var_four)

When the conditional part of an if-statement is long enough to require that it be written across multiple

lines, it's worth noting that the combination of a two character keyword (i.e. if), plus a single space, plus

an opening parenthesis creates a natural 4-space indent for the subsequent lines of the multiline

conditional. This can produce a visual conflict with the indented suite of code nested inside the

if-statement, which would also naturally be indented to 4 spaces. This PEP takes no explicit position on

how (or whether) to further visually distinguish such conditional lines from the nested suite inside the

if-statement. Acceptable options in this situation include, but are not limited to:

# No extra indentation.

if (this_is_one_thing and

that_is_another_thing):

do_something()

# Add a comment, which will provide some distinction in editors

View document source. Generated on: 2020-03-18 05:36 UTC. Generated by Docutils from reStructuredText

source.

For flowing long blocks of text with fewer structural restrictions (docstrings or comments), the line length

should be limited to 72 characters.

Limiting the required editor window width makes it possible to have several files open side-by-side, and

works well when using code review tools that present the two versions in adjacent columns.

The default wrapping in most tools disrupts the visual structure of the code, making it more difficult to

understand. The limits are chosen to avoid wrapping in editors with the window width set to 80, even if the

tool places a marker glyph in the final column when wrapping lines. Some web based tools may not offer

dynamic line wrapping at all.

Some teams strongly prefer a longer line length. For code maintained exclusively or primarily by a team

that can reach agreement on this issue, it is okay to increase the line length limit up to 99 characters,

provided that comments and docstrings are still wrapped at 72 characters.

The Python standard library is conservative and requires limiting lines to 79 characters (and

docstrings/comments to 72).

The preferred way of wrapping long lines is by using Python's implied line continuation inside parentheses,

brackets and braces. Long lines can be broken over multiple lines by wrapping expressions in

parentheses. These should be used in preference to using a backslash for line continuation.

Backslashes may still be appropriate at times. For example, long, multiple with-statements cannot use

implicit continuation, so backslashes are acceptable:

with open('/path/to/some/file/you/want/to/read') as file_1, \

open('/path/to/some/file/being/written', 'w') as file_2:

file_2.write(file_1.read())

(See the previous discussion on multiline if-statements for further thoughts on the indentation of such

multiline with-statements.)

Another such case is with assert statements.

Make sure to indent the continued line appropriately.

Should a Line Break Before or After a Binary Operator?

For decades the recommended style was to break after binary operators. But this can hurt readability in

two ways: the operators tend to get scattered across different columns on the screen, and each operator is

moved away from its operand and onto the previous line. Here, the eye has to do extra work to tell which

items are added and which are subtracted:

# No: operators sit far away from their operands

income = (gross_wages +

taxable_interest +

(dividends - qualified_dividends) -

ira_deduction -

student_loan_interest)

To solve this readability problem, mathematicians and their publishers follow the opposite convention.

Donald Knuth explains the traditional rule in his Computers and Typesetting series: "Although formulas

within a paragraph always break after binary operations and relations, displayed formulas always break

before binary operations"

Following the tradition from mathematics usually results in more readable code:

View document source. Generated on: 2020-03-18 05:36 UTC. Generated by Docutils from reStructuredText

source.

剩余21页未读，继续阅读

评论收藏

内容反馈

SπKe.X

粉丝: 5

Python编程规范PEP8.pdf

PEP8Python编码规范.pdf

python编程规范.pdf

Python_PEP8_代码规范.pdf

python-pep8编码规范

Python PEP8 编码规范中文版.zip

PEP 8 --python 编码规范中英文对照（更新）

Python PEP8 编码规范中文版.pdf

PEP8 Python编码规范

Python PEP8编码规范

PEP8 Python 编码规范

Python 常用 PEP8 编码规范详解

Python PEP8 编码规范中文版

PEP8Python 编码规范

简明Python代码规范 Python编程规范 Python开发代码规范与标准 Python编程开发习惯 共13页.pdf

Python极客项目编程.zip

Python入门指南(纯中文版v2.7).pdf

python编程规范

PEP8规范-python相关

python编码规范.pdf

PEP8代码规范

PEP8中文版

Python代码规范.pdf

最新资源

简明Python代码规范 Python编程规范 Python开发代码规范与标准 Python编程开发习惯共13页.pdf