没有合适的资源?快使用搜索试试~ 我知道了~
首页python编码规范(英文原版)
资源详情
资源评论
资源推荐
Python (/) >>>
Python Developer's Guide (/dev/) >>>
PEP Index (/dev/peps/) >>>
PEP 8 - Style Guide for Python Code
PEP 8 - Style Guide for Python Code
PEP: 8
Title: Style Guide for Python Code
Ver sion: e98737176f1d
Last-Modified: 2014-08-31 20:18:33 -0700 (Sun, 31 Aug 2014) (https://hg.python.org/peps/file/tip/pep-0008.txt)
Author: Guido van Rossum <guido at python.org>, Barry Warsaw <barry at python.org>, Nick Coghlan <ncoghlan at gmail.com>
Sta tus: Active
Type: Process
Cr eated: 05-Jul-2001
Post-Histor y: 05-Jul-2001, 01-Aug-2013
Contents
Introduction (#introduction)
A Foolish Consistency is the Hobgoblin of Little Minds (#a-foolish-consistency-is-the-hobgoblin-of-little-minds)
Code lay-out (#code-lay-out)
Indentation (#indentation)
Tabs or Spaces? (#tabs-or-spaces)
Maximum Line Length (#maximum-line-length)
Blank Lines (#blank-lines)
Source File Encoding (#source-file-encoding)
Imports (#imports)
Whitespace in Expressions and Statements (#whitespace-in-expressions-and-statements)
Pet Peeves (#pet-peeves)
Other Recommendations (#other-recommendations)
Comments (#comments)
Block Comments (#block-comments)
Inline Comments (#inline-comments)
Documentation Strings (#documentation-strings)
Version Bookkeeping (#version-bookkeeping)
Naming Conventions (#naming-conventions)
Overriding Principle (#overriding-principle)
Descriptive: Naming Styles (#descriptive-naming-styles)
Prescriptive: Naming Conventions (#prescriptive-naming-conventions)
Names to Avoid (#names-to-avoid)
Package and Module Names (#package-and-module-names)
Class Names (#class-names)
Exception Names (#exception-names)
Global Variable Names (#global-variable-names)
Function Names (#function-names)
Function and method arguments (#function-and-method-arguments)
Method Names and Instance Variables (#method-names-and-instance-variables)
Constants (#constants)
Designing for inheritance (#designing-for-inheritance)
Public and internal interfaces (#public-and-internal-interfaces)
Programming Recommendations (#programming-recommendations)
References (#references)
Copyright (#copyright)
Introduction (#id9)
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 [1] (#id5) .
This document and PEP 257 (/dev/peps/pep-0257) (Docstring Conventions) were adapted from Guido's original Python Style Guide essay, with some additions from Barry's style guide [2] (#id6) .
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 (#id10)
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 (/dev/peps/pep-0020) 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 most
important.
But most importantly: know when to be inconsistent -- sometimes the style guide just doesn't apply. 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 (#id11)
Indentation (#id12)
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 [5] (#fn-hi) . When
using a hanging indent the following considerations should be applied; 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)
# More indentation included to distinguish this 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:
剩余32页未读,继续阅读
hotworld
- 粉丝: 6
- 资源: 6
上传资源 快速赚钱
- 我的内容管理 收起
- 我的资源 快来上传第一个资源
- 我的收益 登录查看自己的收益
- 我的积分 登录查看自己的积分
- 我的C币 登录后查看C币余额
- 我的收藏
- 我的下载
- 下载帮助
会员权益专享
最新资源
- RTL8188FU-Linux-v5.7.4.2-36687.20200602.tar(20765).gz
- c++校园超市商品信息管理系统课程设计说明书(含源代码) (2).pdf
- 建筑供配电系统相关课件.pptx
- 企业管理规章制度及管理模式.doc
- vb打开摄像头.doc
- 云计算-可信计算中认证协议改进方案.pdf
- [详细完整版]单片机编程4.ppt
- c语言常用算法.pdf
- c++经典程序代码大全.pdf
- 单片机数字时钟资料.doc
- 11项目管理前沿1.0.pptx
- 基于ssm的“魅力”繁峙宣传网站的设计与实现论文.doc
- 智慧交通综合解决方案.pptx
- 建筑防潮设计-PowerPointPresentati.pptx
- SPC统计过程控制程序.pptx
- SPC统计方法基础知识.pptx
资源上传下载、课程学习等过程中有任何疑问或建议,欢迎提出宝贵意见哦~我们会及时处理!
点击此处反馈
安全验证
文档复制为VIP权益,开通VIP直接复制
信息提交成功
评论0