无极门户网站,电器网站建设目的,网页游戏怎么在手机上玩,中国广告公司NOTE(注意): 随着时间的推移#xff0c;更好的编程方式可能会陆续出现#xff0c;以下基于PEP8整理总结于2023-12-18. 由于加入了自己的一些见解#xff0c;所以本文并不是PEP8的翻译版本#xff0c;所以跟PEP8并不100%相同。其中样例代码只摘取了经典的常见的一部分。 以下…NOTE(注意): 随着时间的推移更好的编程方式可能会陆续出现以下基于PEP8整理总结于2023-12-18. 由于加入了自己的一些见解所以本文并不是PEP8的翻译版本所以跟PEP8并不100%相同。其中样例代码只摘取了经典的常见的一部分。 以下部分内容仅代表个人观点请理性对待如有错误的地方欢迎指出。 希望本文能帮助初学python的同学。 为了方便解答一些问题热爱python的以及正在学习python的小伙伴可以来这里一起交流学习Q企鹅裙826238287
1、缩进
缩进使用四个空格缩进(可设置Tab键为四个空格) 单行太多时需要换行应该优先使用Python隐式的换行方式即利用圆括号、方括号和大括号内的行连接垂直对齐或者使用悬挂缩进(悬挂缩进个人感觉不够美观)。
# 推荐的示范:# 函数
# 额外添加4个空格(额外的缩进级别)以区分参数和其他参数
# 即缩进两个级别首行无参数
def long_function_name(var_one, var_two, var_three,var_four):print(var_one)# 多行结构
# 多行结构中的右大括号/大括号/圆括号可以排在列表最后一行的第一个非空白字符下面
# 或它可以排在开始多行结构的行的第一个字符下面
my_list [1, 2, 3,4, 5, 6,
]
result some_function_that_takes_arguments(a, b, c,d, e, f,
)2、制表符(Tab)和空格
空格是首选的缩进方法。 Python 3 不允许混合使用制表符和空格进行缩进。 当历史代码使用Tab缩进时请跟历史代码保持一致否则请使用4空格进行缩进。 几乎99%的代码都是使用4空格缩进(没有实际的调研资深程序员的经验)
3、最大行长度
单行字符数量最大79个字符许多IDE都支持设置最大字符长度 建议在开始一个新项目时提前设置好便于阅读。 当然许多已有的历史项目可能有自己的约定比如120如果有请与历史项目的CodeFormat保持一致。不然可能会让项目代码看起来丑陋无比(当然它并不影响运行)。
4、运算符前后断线
对于过长的运算表达式需要在运算符位置换行具体是在运算符前换行还是运算符后换行这个颇有争议。 从几十年经验的老程序员建议来看是在运算符后面换行即如下
#运算符后换行
income (gross_wages taxable_interest (dividends - qualified_dividends) -ira_deduction -student_loan_interest)但是数学家Donald Knuth在计算机和排字领域中分析了很多结论就是操作符前换行更易读如下
# 运算符前换行
income (gross_wages taxable_interest (dividends - qualified_dividends)- ira_deduction- student_loan_interest)这里建议根历史项目保持一致如果是新项目个人建议运算符前换行更易读。
5、空白行
1、顶层函数和类定义之间应该有两个空行 2、类内方法的定义间隔一个空行 3、功能类别分组可使用两个空行进行简单分组(易读) Python接受control-L(即^L)格式换行字符作为空白符;许多工具将这些字符视为页面分隔符因此您可以使用它们来分隔文件中相关部分的页面。(符合标准但不推荐兼容性不好)
def top_function():passclass MyClass(object): # 与上方顶层函数空两行def __init__(self):passdef func_1(self):passdef func_2(self): # 与上方func_1类方法空一行pass6、源文件编码
核心Python发行版中的代码应该始终使用UTF-8并且不应该有编码声明。 在标准库中非utf-8编码应该仅用于测试目的。 尽量避免使用非ascii字符最好仅用于表示地点和人名。 如果使用非ascii字符作为数据请避免使用嘈杂的Unicode字符。 Python标准库中的所有标识符必须使用纯ascii标识符 并且应该尽可能使用英语单词(在许多情况下使用非英语的缩写和技术术语)。 使用英文通常便于国际化当然在某些特殊情况下可以使用其他的比如中文拼音(中国文化博大精深非专有名词应尽量避免使用拼音容易存在歧义比如shijie你很难知道我要表达的是“石阶”还是“世界”)
7、Imports包导入
1、导入通常要在单独行 2、导入应始终放在文件顶部 3、导入应该按如下顺序分组 (1)、标准库导入 (2)、相关的第三方库导入 (3)、本地应用程序/库的导入 4、每组导入应用一个空白行进行分隔 5、优先使用绝对导入而不是相对(易读性好错误提示更友好不容易出现循环引用) 6、避免通配符全量from mypkg import *导入
# 推荐示范
import os
import sysfrom subprocess import Popen, PIPEimport mypkg.sibling
from mypkg import sibling
from mypkg.sibling import example8、模块级的DunderNames(双下划线开头结尾的变量名)
如__all__ __author__ __version__等应放在模块文档字符串(docstrings)之后但要在除__future__ import之外的任何导入语句之前。 future import比较特殊Python强制要求future-imports必须出现在模块中除docstrings之外的任何其他代码之前
This is the example module.
This is docstrings.
This module does stuff.
from __future__ import barry_as_FLUFL # docstring后面其他的import和DunderNames前面__all__ [a, b, c]
__version__ 0.1
__author__ Cardinal Biggles # 除__future__ import之外的任何import语句之前import os
import sys9、字符引号
在Python中单引号字符串和双引号字符串是相同的。PEP没有对此提出建议。 可以选择一种方式并一直使用下去。 但是当字符串包含单引号或双引号字符时请使用另一个字符以避免字符串中出现反斜杠。它提高了可读性。 个人推荐字符串优先使用单引号因为相比于其他语言需要使用双引号来表示字符串来说它比较Pythonic Pythonic不太好解释它的意思总之就是比较有python的个性和特点的意思简单来说就是python代码更优雅
10、表达式和语句中的空格
避免出现杂乱的空格
# 推荐示范:
spam(ham[1], {eggs: 2})
foo (0,)
if x 4: print(x, y); x, y y, x# 不推荐的写法
spam( ham[ 1 ], { eggs: 2 } )
bar (0, )
if x 4 : print(x , y) ; x , y y , x空格的使用比较复杂和繁琐这里只能列举出常见的通常在编程的时候IDE会给我们辅助提示并不需要记忆太多东西。 其他一些建议 避免在任何地方留下空格。因为它通常是不可见的它可能会令人困惑:例如反斜杠后面跟着空格和换行符不算作行继续标记。 总是在这些二元操作符的两边分别用一个空格括起来:赋值()、增量赋值(、-等)、比较(、、、!、、、、in、not in、is、is not)、布尔值(and、or、not)。 如果使用具有不同优先级的操作符请考虑在具有最低优先级的操作符周围添加空白。用你自己的判断;但是永远不要使用多个空格并且在二进制操作符的两边总是有相同数量的空白。
11、尾部逗号的使用
尾部的逗号通常是可选的但当形成一个元组时必须强制使用逗号为了清楚起见建议将括号明显的写出来(而不是隐式的生成)。
# 推荐示范显示指明括号
FILES (setup.cfg,)# 不推荐示范隐式指明括号容易错误排查问题难以排查
FILES setup.cfg,多余的尾部逗号是有用的情况当使用版本控制系统时当期望值、参数或导入项的列表随着时间的推移而扩展时它们通常是有用的。 该模式是将每个值(等)单独放在一行上总是在后面添加逗号并在下一行添加右括号/大括号/大括号。 但是在结束分隔符的同一行上有一个尾随逗号是没有意义的(除了单例元组)
# 推荐示范:
FILES [setup.cfg,tox.ini,]
initialize(FILES,errorTrue,)# 不推荐示范
FILES [setup.cfg, tox.ini,]
initialize(FILES, errorTrue,)12、注释
重要重要重要 与代码功能不符的的注释比没有注释更糟糕。当代码发生变化时,总是优先注意保持注释最新! 当一长段代码的返回值应该是True的时候你却在注释上标记的是False如果被其他程序员看到了这个时候我建议你去多穿几层厚的衣服然后带个安全系数高的头盔比你继续写代码来的更靠谱
程序员的苦衷不想看没有注释的代码不想写有注释的代码。 养成良好的习惯给你的代码加上注释吧。程序员何必为难程序员。
评论的规范 1、注释应该是完整的句子。第一个单词应该大写除非它是以小写字母开头的标识符(永远不要改变标识符的大小写!) 2、块注释通常由一个或多个由完整句子组成的段落组成每个句子以句号结尾。 3、在多句注释中除了最后一句之外你应该在句子结束后使用一到两个空格。 4、确保注释足够的清晰。 5、来自非英语国家的Python程序员:请用英语写你的注释除非你120%确定代码永远不会被不讲你的语言的人阅读。 个人的一些建议绝大多数代码都是闭源的如果团队中不是来自各个国家的成员注释建议使用母语他能更好的和更清楚的表达意思使用它国语言并不能彰显你有多么的NB反而它有时候更容易Gu_fcsdn让队友误解这是不利的。当然一些对其他字符或语言兼容不好的系统要特殊对待不过除了专有领域和古董设备以外这种情况几乎不存在了。
块注释 块注释通常适用于跟踪它们的一些(或所有)代码,并被缩进与代码相同的级别。每一行的block注释从#和一个空格开始(除非它是在注释中输入的文本)。 块注释中的段落由包含单个#的行分隔。
内联注释 内联注释是与语句在同一行的注释。内联注释与语句之间应该至少间隔两个空格。它们应该以#和一个空格开头。 内联注释是不必要的如果它们陈述了显而易见的事情实际上会分散注意力。 在某些情况下是必要的如下
# 无必要的
x x 1 # 对x进行加一# 有必要的
x x 1 # x加一进行补偿逻辑边界文档注释 通常使用三引号(单引号/双引号)进行文档注释 为所有公共模块、函数、类和方法编写文档字符串。文档字符串对于非公共方法不是必需的但是您应该有一个注释来描述该方法的功能。这个注释应该出现在定义符之后。 1、对于多行文档注释来说头部三引号通常为总结或返回值结尾三引号请保持在独立行 2、对于单行文档注释来说三引号不应该在独立行而应该在一行
# 多行文档注释
Return a foobangOptional plotz says to frobnicate the bizbaz first.
# 单行文档注释
Return an ex-parrot.13、命名约定
Python库的命名约定有点乱所以我们永远不会完全一致——尽管如此这里是目前推荐的命名标准。 新的模块和包(包括第三方框架)应该按照这些标准编写但是如果现有的库具有不同的风格则优先考虑内部一致性。
重要部分 作为API的公共部分对用户可见的名称应该遵循反映用法而不是实现的约定。
命名风格
b (单个小写字母)B (单个大写字母)lowercase 单个小写单词lower_case_with_underscores 多个单词下划线表示UPPERCASE 单个大写单词UPPER_CASE_WITH_UNDERSCORES 单个大写单词下划线表示CapitalizedWords 驼峰命名通常用于类名在CapWords中使用首字母缩写时首字母缩写的所有字母都要大写。因此HTTPServerError比HttpServerError更好mixedCase (不同于大写单词的首字母小写字符小驼峰)Capitalized_Words_With_Underscores (这是不推荐的写法!)
此外可以识别以下使用下划线开头或结尾的特殊形式(这些通常可以与任何大小写约定结合使用):
_single_leading_underscore: 单下划线开头的变量名弱“仅内部使用”。from M import *不导入名称单下划线开始的对象。single_trailing_underscore_: 按照约定常规使用通常用于避免与Python关键字冲突而在尾部增加单个下划线例如tkinter.Toplevel(master, class_ClassName)__double_leading_underscore: 当命名一个类属性时调用名称混淆(在类FooBar中__boo变成了_FooBar__boo)。__double_leading_and_trailing_underscore__: 双下划线开头和结尾的变量存在于用户控制的命名空间中的“魔法”对象或属性。例如__init__ __import__或__file__。永远不要编造这样的名字,只按照文档的要求使用它们。
命名规则 1、避免使用的命名 不要使用字符’ l (小写字母el) ’ O ‘(大写字母oh)或’ I (大写字母eye)作为单字符变量名。 在某些字体中这些字符与数字1和0无法区分。当你想用“l”的时候就用“L”代替。 2、保持ASCII码兼容 标准库中使用的标识符必须与ASCII兼容。 3、包名和模块名 模块应该有简短的、全小写的名称。如果可以提高可读性可以在模块名中使用下划线。Python包也应该有简短的、全小写的名称尽管不鼓励使用下划线。 当用C或C编写的扩展模块附带提供更高级别(例如更面向对象)接口的Python模块时c/c模块有一个前导下划线(例如_socket)。 4、类名 类名通常应该使用CapWords约定。大驼峰 函数的命名约定可以在接口被记录并主要作为可调用对象使用的情况下使用。 请注意,内置名称的约定是单独的:大多数内置名称都是单个单词(或两个单词一起运行),使用的CapWords约定只用于异常名称和内置常量。 5、类型变量名 PEP 484中引入的类型变量的名称通常应该使用CapWords更倾向于使用短名称:T, AnyStr, Num。建议在用于声明协变或逆变行为的变量后添加后缀_co或_contra:
from typing import TypeVarVT_co TypeVar(VT_co, covariantTrue)
KT_contra TypeVar(KT_contra, contravariantTrue)6、异常命名 因为异常应该是类所以这里适用类命名约定。但是您应该在异常名称上使用后缀“Error”如CustomValueError(如果异常实际上是错误)。 7、全局变量命名 (我们希望这些变量只能在一个模块中使用。)这些约定与函数的约定大致相同。 from M import * 应该使用__all__机制来防止输出globals,或者使用更旧的前缀,用下划线来前缀(你可能想要做的),以指示这些全局函数是“非开放模块”。 8、函数和变量命名 函数名应该是小写的必要时用下划线分隔以提高可读性。 变量名遵循与函数名相同的约定。 mixedCase风格只允许在已经是流行风格的上下文中使用(例如threading.py)以保持向后兼容性。 9、函数和方法参数 总是使用self作为实例方法的第一个参数。 总是将cls作为类方法的第一个参数。 如果函数参数的名称与保留关键字冲突通常最好在后面附加一个下划线而不是使用缩写或拼写错误。因此class_比clss好。(也许最好是使用同义词来避免这种冲突。) 10、方法名和实例变量 使用函数命名规则:小写字母必要时用下划线分隔以提高可读性。 只对非公共方法和实例变量使用一个前导下划线。 为了避免与子类的名称冲突请使用两个前导下划线来调用Python的名称混淆规则。 Python用类名混淆了这些名称:如果类Foo有一个名为__a的属性它不能被Foo.__a访问。(如果用户想用户仍然可以通过调用Foo._Foo__a来获得访问权。)通常双前导下划线应该仅用于避免与设计为子类化的类中的属性发生名称冲突。 注意:关于__names的使用存在一些争议。 11、常量 常量通常在一个模块级别上定义,并用所有大写字母写在分隔字上。示例包括MAX_OVERFLOW溢出和TOTAL。 12、继承的设计 始终决定一个类的方法和实例变量(统称为“属性”)应该是公共的还是非公共的。如果有疑问选择非公开的;稍后将其设置为公共属性比将公共属性设置为非公共属性更容易。 公共属性是那些期望与您的类不相关的客户使用的,以避免向后不兼容的更改。非公开(non-public)属性是那些不打算被第三方使用的属性;你不能保证“属性”不会改变或被删除。 我们在这里没有使用术语“私有”因为在Python中没有属性是真正私有的。 另一类属性是“子类API”的一部分(在其他语言中通常称为“protected”)。有些类被设计为可以继承以扩展或修改类行为的某些方面。在设计这样的类时要注意明确地决定哪些属性是公共的哪些属性是子类API的一部分哪些属性只能由基类使用。 考虑到这一点以下是python指南
公共属性不应该有前导下划线。如果公共属性名与保留关键字冲突请在属性名后面添加一个下划线。这比缩写或错误的拼写更可取。(然而尽管有此规则cls是已知为类的任何变量或参数的首选拼写特别是类方法的第一个参数。) 注:请参阅上面关于类方法的参数名称推荐。对于简单的公共数据属性最好只公开属性名称不使用复杂的accessor/mutator方法。请记住如果您发现一个简单的数据属性需要发展函数行为那么Python为将来的增强提供了一条简单的途径。在这种情况下使用属性将功能实现隐藏在简单的数据属性访问语法之后. 注1尽量避免函数行为的副作用尽管诸如缓存之类的副作用通常是好的 注2避免使用属性来计算昂贵的操作;属性符号使调用者相信访问(相对)便捷。如果您的类打算被子类化并且您有不希望子类使用的属性请考虑使用双下划线前导而不带下划线来命名它们。这调用了Python的名称混淆算法其中类的名称被混淆为属性名称。如果子类无意中包含具有相同名称的属性这有助于避免属性名称冲突。 注1注意在修改后的名称中只使用了简单的类名因此如果子类选择了相同的类名和属性名仍然可能出现名称冲突。 注2名称混淆会使某些用途(如调试和__getattr__())变得不那么方便。然而名称混淆算法有很好的文档记录并且易于手动执行。 注3不是每个人都喜欢人的名字。试着平衡需要避免意外名称与潜在使用的高级调用者的冲突。
13、公共和内部接口 任何向后兼容性保证只适用于公共接口。因此重要的是用户能够清楚地区分公共接口和内部接口。 文档化的接口被认为是公共的除非文档显式地声明它们是临时的或免除通常的向后兼容性保证的内部接口。所有未归档的接口都应该假定是内部的。 为了更好地支持自省模块应该使用__all__属性在其公共API中显式声明名称。将__all__设置为空列表表明该模块没有公共API。 即使正确设置了__all__内部接口(包、模块、类、函数、属性或其他名称)仍应以单个下划线作为前缀。 如果任何包含名称空间(包、模块或类)被认为是内部的那么接口也被认为是内部的。 导入的名称应始终被视为实现细节。其他模块不能依赖于对这些导入名称的间接访问除非它们是包含模块API如os.path的显式文档部分。路径或包的__init__模块该模块公开子模块的功能。
14、编程建议
代码应该以一种不适合其他Python实现的方式编写(PyPy、Jython、IronPython、Cython、Psyco等)。 例如,不要依赖CPython有效地实现表单a b或a a b的语句的内串连接。 在库的性能敏感部分,应使用. join()这将确保跨各种实现的连接在线性时间内发生。与None之类的单例比较应该总是用is或is not来完成,永远不要等号运算符。另外当你真正的意思是if x is not None时要注意不要写if x,例如在测试默认为None的变量或参数是否被设置为其他值时。另一个值的类型(例如容器)在布尔上下文中可能为false!用is not运算符而不是not ... is多少。虽然这两个表达式在功能上是相同的但前者更具可读性和首选。
# 推荐示范:
if foo is not None:# 不推荐示范:
if not foo is None:在实现具有丰富比较的排序操作时,最好实现所有6个操作(__eq__,__ne__,__lt__,__le__,__gt__,__ge__),而不是依赖其他代码,只进行一个特别的比较。为了尽量减少工作量functools.total_ordering()装饰器提供了一个工具来生成缺失的比较方法。始终使用def语句而不是将lambda表达式直接绑定到标识符的赋值语句。
# 推荐的示范:
def f(x): return 2*x# 不推荐的示范:
f lambda x: 2*x第一种形式意味着结果函数对象的名称特别为f而不是通用的lambda。一般来说这对于回溯和字符串表示更有用。赋值语句的使用消除了lambda表达式相对于显式def语句所能提供的唯一好处(即它可以嵌入到更大的表达式中)。
从Exception而不是BaseException派生异常。从BaseException直接继承是为那些捕获它们几乎总是错误的异常保留的。 基于捕获异常的代码可能需要的区别来设计异常层次结构而不是基于引发异常的位置。目的是回答这个问题“哪里出了问题?”而不是仅仅指出“发生了问题” 这里适用于类命名约定但如果异常是错误则应该在异常类后面加上后缀“Error”。用于非本地流控制或其他形式的信令的非错误异常不需要特殊后缀。适当地使用异常链。应该使用raise X from Y来指示显式替换而不会丢失原始的回溯。 当故意替换内部异常时(使用 raise X from None)确保相关细节被转移到新异常(例如在将KeyError转换为AttributeError时保留属性名称或者在新异常消息中嵌入原始异常的文本)。在捕捉异常时尽可能指定特定的异常而不是使用except
# 指定特定异常ImportError
try:import platform_specific_module
except ImportError:platform_specific_module None除非 except 将捕获SystemExit和KeyboardInterrupt异常,使中断程序与Control-C更加困难,并可以掩盖其他问题。如果您想要捕捉到信号程序错误的所有异常,则使用except Exception:(等价于except BaseException:)。 一个好的经验法则是将“except”从句的使用限制在两种情况下: 1、如果异常处理程序将打印或日志记录示踪器,至少用户将意识到发生了错误。 2、如果代码需要做一些清理工作然后让异常通过raise向上传播try...finally将是一个更好的方法来处理这种情况。
在捕获操作系统错误时请选择Python 3.3中引入的显式异常层次结构而不是过度认定errno值。此外对于所有try/except子句将try子句限制为所需的绝对最小代码量。同样这避免了掩盖bug
# 推荐示范:
try:value collection[key]
except KeyError:return key_not_found(key)
else:return handle_value(value) # 不推荐示范:
try:# 范围太广return handle_value(collection[key])
except KeyError:# 这还将捕获由handle_value()引发的KeyErrorreturn key_not_found(key)当资源是特定代码段的局部资源时使用with语句确保在使用后及时可靠地清理它。try/finally语句也是可以接受的。只要它们做的不是获取和释放资源上下文管理器应该通过单独的函数或方法调用
# 推荐示例:
with conn.begin_transaction():do_stuff_in_transaction(conn)# 不推荐示例:
with conn:do_stuff_in_transaction(conn)后一个例子没有提供任何信息来表明__enter__和__exit__方法除了在事务结束后关闭连接之外正在做其他事情。在这种情况下明确是很重要的。
在返回语句中保持一致。函数中的所有返回语句都应该返回表达式或者它们都不应该返回表达式。如果任何return语句返回一个表达式任何没有返回值的return语句都应该显式地将其声明为return None并且应该在函数末尾显示一个显式的return语句(如果可达的话)
# 推荐示例:
def foo(x):if x 0:return math.sqrt(x)else:return Nonedef bar(x):if x 0:return Nonereturn math.sqrt(x)# 不推荐示例:
def foo(x):if x 0:return math.sqrt(x)def bar(x):if x 0:returnreturn math.sqrt(x)使用.startswith()和.endswith()代替字符串切片来检查前缀或后缀。 startswith()和endswith()更简洁更不容易出错
# 推荐示例:
if foo.startswith(bar):# 不推荐示例:
if foo[:3] bar:对象类型比较应该总是使用isinstance(),而不是直接比较类型
# 推荐示例:
if isinstance(obj, int):# 不推荐示例:
if type(obj) is type(1):对于序列(字符串、列表、元组)使用空序列为假的判断方式
# 推荐示例:
if not seq:
if seq:# 不推荐示例:
if len(seq):
if not len(seq):不要编写依赖于重要末尾空白的字符串文字。这样的尾随空格在视觉上是无法区分的一些编辑器(或者最近的reindent.py)会去除它们。不要使用将布尔值与True或False进行比较
# 推荐示例:
if greeting:# 不推荐示例:
if greeting True:# 更糟糕的示例
if greeting is True:使用流控制语句return/break/continue在try...finally结构的finally中不鼓励流控制语句跳转到finally结构之外因为这样的语句将隐式取消任何通过finally套件传递的异常
# 不推荐的示例:
def foo():try:1 / 0finally:return 4215、变量注释
1、模块级变量、类和实例变量以及局部变量的注释应该在冒号后面有一个空格 2、冒号前不应有空格 3、如果赋值项有右手边那么等式两边应该正好有一个空格
# 推荐示例:
code: intclass Point:coords: Tuple[int, int]label: str unknown# 不推荐示例:
code:int # 冒号后没有空格
code : int # 冒号前的空格class Test:result: int0 # 等号周围没有空格PS:尽管Python 3.6接受PEP 526但变量注释语法是所有Python版本上存根文件的首选语法(详细信息请参阅PEP 484)。
15、最后
以上内容的整理和总结均基于 PEP-8 规范并增加了自己的一些见解编写。代码风格从来都是一个行为习惯而不是强制性的规范所以一些不推荐的示例依然可以正常运行只是为了更好的便于理解和防止一些奇怪的错误出现不宜排查而总结的一套比较好的编程习惯。它不能衡量你技术的高低但是可以让大家都保持一个好习惯。
