<h3 style="text-indent: 27.1pt">
<span lang="EN-US">1 原则
<p style="text-indent: 24.0pt">在开始讨论<span lang="EN-US">Python社区所采用的具体标准或是由其他人推荐的建议之前,考虑一些总体原则非常重要。
<p style="text-indent: 24.0pt">请记住可读性标准的目标是提升可读性。这些规则存在的目的就是为了帮助人读写代码,而不是相反。
<p style="text-indent: 24.0pt">本小节讨论你所需记住的一些原则。
<h4 style="text-indent: 28.1pt">
<span lang="EN-US">1.1 <span style="font-family: 宋体">假定你的代码需要维护
添加一部分或对其维护。这是由于很难预料到未来的需求,以及低估自己造成的倾向。然而,所写代码很少不被修改一直存在。
代码会一劳永逸的无需之后进行阅读、调试或修补,那么你就会非常容易陷入忽视其他可读性原则的境地,这仅仅是因为你相信这次并不重要。
代码无需维护的直觉的不信任才是上策。稳赚不赔的办法是赌自己将会再次见到自己写的代码。即使你不维护,那也需要其他人维护。
代码风格和代码结构层面来讲,代码都要尽量满足内部一致性。无论是哪种格式化规则,代码风格都要贯穿项目保持一致。代码结构的一致性也就是同样类型的代码放到一起。这样项目容易把控。
代码的结构与其他人保持一致,如果一个新来的开发人员打开你的项目,你不应该让他的反应是:我从来没见过像这样的东 西。社区指导原则很重要,因为这就是开发人员加入到你的项目预期所见。类似的,以及相同的原因,请认真看待在使用特定框架时完成任务以及组织代码所采用 的标准。
)的主要意思就是关于存在的研究。在哲学上(在该领域这个词很常用)存在论是关于现实与存在本质的研究,是形而上学的子集。
事物在程序中如何存在。你如何将概念转化为在数据库中表示?亦或是用类结构表示?
代码的方式。是否使用继承或是组合来组织两个类之间的关系?数据库中用哪个表完成这项功能或是这个列属于谁?
在写代码之前先思考。尤其是思考程序希望实现的目标,以及程序之间如何交互。程序是一个对象与数据交互的世界。那么,它们之间协作所需遵循的规则是什么?
代码时,请考虑随着时间重复使用的值将会变更的情况。该值是否被用于多个模块或函数中?如果必要,需要花费多大代价修改它?
函数。你是否在程序中有大量的重复的代码?如果这些重复代码行数较多,可以考虑将其抽象到一个函数中,如果出现修改代码的需求,则更容易管理。
如果需要变更该代码,变更该代码的所有位置所需要的成本是多少?
代码是一个故事。它是所发生故事的说明,在用户与程序交互过程中,从开始到结束。程序从某一点开始(可能带有一些输入),沿着一系列选择自己的冒险故事步骤到达终点,并结束(很可能带有一些输出结果)。
代码之前就添加一段注释,用于解释代码的功能。如果代码是一个故事,那么注释就是故事的解释与旁白。
代码(例如,当尝试解决问题或维护代码时),然后可以从零开始快速了解所需维护的代码,这样就可以专注于代码本身所代表的意义。
代码意图。它可以回答这样的问题:写这段代码的人希望完成的目标是什么?偶尔,还可以帮助回答问题:为什么以这种方式完成工作?这些问题是在你阅读代码时很自然会问的,为这些问题提供答案将会帮助了解这些内容。
代码中不显而易见或复杂部分的原理。如果使用了有点复杂的算法,请考虑将指向解释模式文章的链接以及其他使用示例加入注释。
代码最重要的原则通俗来讲就是奥卡姆剃刀原则:最简单的解决方案通常是最好的。在他的之禅博文 (),该页面是编程格言的集合(例如,在控制台中输入就可以看到这篇),也包括了类似下面这句如果你无法向人描述你的方案,那肯定不是一个好方案。
代码如何运行与代码外观层面都生效。当提到代码运行时,简单的系统更加容易维护。实现的简单化意味着更少引入复杂的,哪些维护你代码的人(包括你自己)更容易凭直觉理解代码所代表的含义,并在不踩坑的前提下为程序增加代码。
代码的外观,请记住,尽可能使得阅读代码就好像是在了解代码所做工作的故事,而不是为了解析词汇。词汇是手段,而故事才是最终目的。写一条诸如不要使 用三元运算符很容易。然而仅仅是遵循这些规则(虽然有价值)并不是代码明晰的充分条件。请专注以尽可能简洁的方式编写和组织代码
标准
社区大部分遵循所谓的()指导原则,由(之父)编写并被包括标准库中的大多数主流项目采用。
的普遍性是其强大的原因之一。该标准被大多数社区项目采纳,因此你可以预计大多数你遇到的代码都遵循该标准。当你以这种方式编写代码时,代码会更加容易阅读,也更容易编写。
中的指导原则都很简单明了。部分重点如下:
使用个空格缩进。不要使用制表符()。
变量应该使用下划线连接,不使用骆驼式命名风格(使用而不是)。类名称以字母开头就是骆驼式命名风格(例如:)。
如果一个变量的用处是:仅内部使用,在变量名称之前加上下划线。
在运算符前后加上单空格(例如,,不是),也包含赋值运算符(而不是),只有在关键字参数情况下不适用,在这种情况下,空格可以省略。
在列表和字典中省略不必要的括号,(例如:而不是)。请阅读代码风格指南获得更多示例以及有关这些规则的更多讨论。
中,如果在一个函数或类中第一个语句是一个字符串,该字符串会自动赋值给一个特殊的变量,该变量在调用(和一些其他的类)时会被使用。
规定文档字符串(该名称可以被望文生义)是必须的。
函数体之前加空行。如果文档字符串有多行,则将结束的双引号单独放一行。
规定最高级的类和函数定义之间有两个空行。
<span style="color: #0000ff">class
<span style="color: #000000"> B(object):<span style="color: #0000ff">pass
代码清单
还规定除了最高级之外,类和函数的定义以一个空行分隔。
<span style="color: #0000ff">pass
<span style="color: #0000ff">def<span style="color: #000000"> bar(self):
<span style="color: #0000ff">pass
代码清单
函数或其他代码段中使用单空行分隔逻辑段是合理的。请考虑在逻辑段之前使用注释解释代码段的作用。
允许绝对路径导入和相对路径导入。在中,解释器会尝试相对导入,如果找不到路径,然后再尝试使用绝对导入。
中,使用特殊语法标记相对当如以()开头正常的导入方式只会尝试相对路径。的语法在以后版本可以使用。除此之外你可以使用关闭隐式相对路径导入。
绝对路径导入。如果不得不使用相对路径,请使用显式导入风格。如果你为或编写代码,请考虑选择中的显式风格。
代码清单
名称,当然可以将这些名称分组到一行中。
<p style="text-indent: 24.0pt">代码清单<span lang="EN-US">4
<p style="text-indent: 24.0pt">除此之外,虽然<span lang="EN-US">PEP 8并没有强制要求,考虑以包来源的方式将导入分组。对于每一组,按照字母表顺序排序。
<p style="text-indent: 24.0pt">另外,在导入时,请不要忘了使用<span lang="EN-US">as关键字给导入的内容起别名。
<div class="cnblogs_code">
foo.bar really_long_name as name