概述

<h3 style="text-indent: 27.1pt">
<span lang="EN-US">1 原则
<p style="text-indent: 24.0pt">在开始讨论<span lang="EN-US">Python社区所采用的具体标准或是由其他人推荐的建议之前，考虑一些总体原则非常重要。

添加一部分或对其维护。这是由于很难预料到未来的需求，以及低估自己造成的倾向。然而，所写代码很少不被修改一直存在。

代码会一劳永逸的无需之后进行阅读、调试或修补，那么你就会非常容易陷入忽视其他可读性原则的境地，这仅仅是因为你相信这次并不重要。

代码无需维护的直觉的不信任才是上策。稳赚不赔的办法是赌自己将会再次见到自己写的代码。即使你不维护，那也需要其他人维护。

代码风格和代码结构层面来讲，代码都要尽量满足内部一致性。无论是哪种格式化规则，代码风格都要贯穿项目保持一致。代码结构的一致性也就是同样类型的代码放到一起。这样项目容易把控。

代码的结构与其他人保持一致，如果一个新来的开发人员打开你的项目，你不应该让他的反应是：我从来没见过像这样的东 西。社区指导原则很重要，因为这就是开发人员加入到你的项目预期所见。类似的，以及相同的原因，请认真看待在使用特定框架时完成任务以及组织代码所采用 的标准。

）的主要意思就是关于存在的研究。在哲学上（在该领域这个词很常用）存在论是关于现实与存在本质的研究，是形而上学的子集。

事物在程序中如何存在。你如何将概念转化为在数据库中表示？亦或是用类结构表示？

代码的方式。是否使用继承或是组合来组织两个类之间的关系？数据库中用哪个表完成这项功能或是这个列属于谁？

在写代码之前先思考。尤其是思考程序希望实现的目标，以及程序之间如何交互。程序是一个对象与数据交互的世界。那么，它们之间协作所需遵循的规则是什么？

代码时，请考虑随着时间重复使用的值将会变更的情况。该值是否被用于多个模块或函数中？如果必要，需要花费多大代价修改它？

函数。你是否在程序中有大量的重复的代码？如果这些重复代码行数较多，可以考虑将其抽象到一个函数中，如果出现修改代码的需求，则更容易管理。

一个问题：如果需要变更该代码，变更该代码的所有位置所需要的成本是多少？

代码是一个故事。它是所发生故事的说明，在用户与程序交互过程中，从开始到结束。程序从某一点开始（可能带有一些输入），沿着一系列选择自己的冒险故事步骤到达终点，并结束（很可能带有一些输出结果）。

代码之前就添加一段注释，用于解释代码的功能。如果代码是一个故事，那么注释就是故事的解释与旁白。

代码（例如，当尝试解决问题或维护代码时），然后可以从零开始快速了解所需维护的代码，这样就可以专注于代码本身所代表的意义。

代码意图。它可以回答这样的问题：写这段代码的人希望完成的目标是什么？偶尔，还可以帮助回答问题：为什么以这种方式完成工作？这些问题是在你阅读代码时很自然会问的，为这些问题提供答案将会帮助了解这些内容。

代码中不显而易见或复杂部分的原理。如果使用了有点复杂的算法，请考虑将指向解释模式文章的链接以及其他使用示例加入注释。

代码最重要的原则通俗来讲就是奥卡姆剃刀原则：最简单的解决方案通常是最好的。在他的之禅博文 （），该页面是编程格言的集合（例如，在控制台中输入就可以看到这篇），也包括了类似下面这句如果你无法向人描述你的方案，那肯定不是一个好方案。

代码如何运行与代码外观层面都生效。当提到代码运行时，简单的系统更加容易维护。实现的简单化意味着更少引入复杂的，哪些维护你代码的人（包括你自己）更容易凭直觉理解代码所代表的含义，并在不踩坑的前提下为程序增加代码。

代码的外观，请记住，尽可能使得阅读代码就好像是在了解代码所做工作的故事，而不是为了解析词汇。词汇是手段，而故事才是最终目的。写一条诸如不要使 用三元运算符很容易。然而仅仅是遵循这些规则（虽然有价值）并不是代码明晰的充分条件。请专注以尽可能简洁的方式编写和组织代码

社区大部分遵循所谓的（）指导原则，由（之父）编写并被包括标准库中的大多数主流项目采用。

的普遍性是其强大的原因之一。该标准被大多数社区项目采纳，因此你可以预计大多数你遇到的代码都遵循该标准。当你以这种方式编写代码时，代码会更加容易阅读，也更容易编写。

中的指导原则都很简单明了。部分重点如下：

使用个空格缩进。不要使用制表符（）。

变量应该使用下划线连接，不使用骆驼式命名风格（使用而不是）。类名称以字母开头就是骆驼式命名风格（例如：）。

如果一个变量的用处是：仅内部使用，在变量名称之前加上下划线。

在运算符前后加上单空格（例如，，不是），也包含赋值运算符（而不是），只有在关键字参数情况下不适用，在这种情况下，空格可以省略。

在列表和字典中省略不必要的括号，（例如：而不是）。请阅读代码风格指南获得更多示例以及有关这些规则的更多讨论。

中，如果在一个函数或类中第一个语句是一个字符串，该字符串会自动赋值给一个特殊的变量，该变量在调用（和一些其他的类）时会被使用。

规定文档字符串（该名称可以被望文生义）是必须的。

函数体之前加空行。如果文档字符串有多行，则将结束的双引号单独放一行。

规定最高级的类和函数定义之间有两个空行。

<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

 foo.bar  really_long_name as name

代码清单

名称或不规范命名的名称。

名称无论何种原因不规范时，别名就很有价值了。

名称，如果没必要使用别名，这会使得代码变得不清晰。无论是使用何种工具，要做到具体情况，具体分析。

名称使用下划线连接，而不要使用骆驼代码风格（例如，而不是）。除此之外，起一个具有描述性的名称同样重要。

名称并不合适，虽然某些情况下这么做也能接受，比如在循环中的变量（例如，）。

函数名称与语言中的常用名称重复，就算是解释器允许也不行。无论在任何情况下，都不要命名某个对象为或。类似的，避免或之类的名称。

一个与类型与关键字同名的变量，惯例是在变量名称之后加下划线；相比修改名称的拼写来说，这么做更加可取。例如，如果你将一个 类作为参数传递给一个函数，那么参数名称应该为，而不是（一个例外是静态方法，按照惯例使用作为第一个参数）。

代码之前。正确使用首字母大写和语法，以及保证拼写正确。

代码变更，那么注释可能也需要随之变更。你应该不希望注释与代码表示的意思相反，这很容易导致混淆。

一个注释头，通常由版本控制系统生成，其中包含文件版本的信息。这使得发现文件被修改变得容易，尤其是在将模块分发给别人使用时。

代码风格最有争议（也是最常被拒绝使用的）的方面是对行长度的限制。要求行长度不超过个字符，文档字符串不超过个字符。

一个寸宽屏显示器的时代。是一个非常流行共享代码的网站，所使用的窗口宽度是个字符。

支持者指出很多人依然使用窄屏或字符长度的终端，甚至仅仅是将代码窗口的宽度设置为小于屏幕宽度。

一个结果。总之，无论是遵循字符宽度的标准或是更宽的标准，你应该按照项目标准的规范编码。当行长度过长时，你应该知道如何处理代码。

代码的最佳方式，如下所示：

代码清单

方法，而不是在换行符之前使用字符。注意在使用诸如之类的操作符时，尽可能将其置于换行符之前。

函数调用也是可以的。列出了许多可接受的方式完成封装。一般规则是使得同级别行缩进保持一致。

x.y.COMMON_PHRASES,x.y.FONT_PREVIEW_PHRASES,],phrase=<span style="color: #800000">'<span style="color: #800000">The quick brown fox jumped over the lazy dogs.<span style="color: #800000">'<span style="color: #000000">,)

<p style="text-indent: 24.0pt">代码清单<span lang="EN-US">7

如果您也喜欢它,动动您的小指点个赞吧