大部分标准库在构建时都要考虑可用性。例如，内置类型的使用是很自然的，其设计
非常易于使用。在这种情况下，Python 可以与你开发程序时所思考的伪代码进行比较。大
部分代码都可以大声朗读出来。例如，任何人都可以理解下面这个代码片段：
my_list = []
if ‘d’ not in my_list:
my_list.append(‘d’)
这就是编写Python 比编写其他语言更加简单的原因之一。在编写程序时，你的思路可
以快速转换成代码。
本章重点介绍编写易于理解和使用的代码的最佳实践，包括：
• 使用PEP 8 描述的命名约定。
• 一组命名最佳实践。
• 常用工具的简要介绍，这些工具可以让你检查是否遵守风格指南。
PEP 8 与命名最佳实践
PEP 8 为编写Python 代码提供了一个风格指南。除了空格缩进、每行最大长度以及其他
与代码布局有关的细节等基本规则之外，PEP 8 还介绍了大部分代码库所遵循的命名约定。
本节给出了这一PEP 的简要总结，并进一步给出了每种元素的命名最佳实践指南。但
你仍然必须阅读PEP 8 文档。
为何要遵守PEP 8 以及何时遵守PEP 8
如果你正在创建一个打算开源的新软件包，那么答案很简单：始终遵守。PEP 8 实际
上是大多数Python 开源软件的标准代码风格。如果你想接受来自其他程序员的任何协作，即使你对最佳代码风格指南有不同的看法，那么也应该坚持遵守PEP 8。这样做的好处是，
其他程序员可以更容易地直接上手你的项目。对于新人来说，代码更容易阅读，因为它的
风格与大多数其他Python 开源包一致。
此外，开始时完全遵守PEP 8，可以让你在未来省时省事。如果你想向公众发布你的
代码，最终其他程序员也会建议你切换到PEP 8。关于对某一特定项目是否真有必要这么
做的争吵，可能会变成一场永无止境并且永远没有赢家的口水战（flame war）。这是令人悲
伤的事实，但为了不失去贡献者，你最终可能还是会被迫与这种风格保持一致。
而且，如果整个项目的代码库处于成熟的开发状态，那么对其重新调整风格（restyling）
可能需要做大量的工作。在某些情况下，重新调整风格可能需要修改几乎每行代码。虽然
大多数修改可以自动化完成（缩进、换行和行尾空格），但这种大规模的代码检查通常会给
所有基于分支的版本控制工作流程引入许多冲突。同时审查这么多修改也很困难。基于上
述原因，许多开源项目都有一条规则：风格修改应该始终包含在单独的拉取/合并
（pull/merge）请求或补丁中，而不影响任何功能或bug。