为什么你的 Python 代码需要美观且显式

Python 贡献者 Tim Peters 于 1999 年向我们介绍了 Python 之禅。二十年后，它的 19 条指导原则在社区中仍然具有现实意义。我们开始我们的 Pythonukkah 庆祝活动——像光明节一样，一个光明节——以 Python 之禅的前两个原则开始：关于美观和显式。

“光明节是光明节，”

“不是一天的礼物，我们有八个疯狂的夜晚。”

—Adam Sandler, 光明节之歌

美观胜于丑陋。

在 计算机程序的构造和解释 (SICP) 中提出了这个观点：“程序必须首先为人编写，其次才是为机器执行。” 机器不在乎美观，但人们在乎。

一个美观的程序是让人乐于阅读的程序。 这首先意味着它是一致的。 像 Black、flake8 和 Pylint 这样的工具非常适合确保表面层面上的合理性。

但更重要的是，只有人类才能判断人类认为什么是美的。 代码审查和协作式编写代码的方法是构建美观代码的唯一现实途径。 倾听他人的意见是软件开发中的一项重要技能。

最后，如果缺乏意愿，所有工具和流程都将变得毫无意义。 如果不欣赏美观的重要性，就永远不会强调编写美观的代码。

这就是为什么这是第一个原则：它是一种使“美观”成为 Python 社区价值观的方式。 它立即回答：“我们真的在乎美观吗？” 我们在乎。

显式胜于隐式。

我们人类崇尚光明，恐惧黑暗。 光明帮助我们理解模糊的图像。 同样，以更显式的方式编程有助于我们理解抽象的概念。 使事物隐式通常是很诱人的。

“为什么 self 显式地作为方法的第一个参数存在？”

有很多技术解释，但所有这些解释都是错误的。 编写一个元类，使显式列出 self 变得不必要，几乎是 Python 程序员的成人礼。（如果您以前从未这样做过，请这样做；这是一个很棒的元类学习练习！）

self 显式存在的原因不是因为 Python 核心开发人员不想将这样的元类作为“默认”元类。 它显式存在的原因是因为需要教授的特殊情况少了一种：第一个参数是显式的。

即使当 Python 允许非显式事物（例如上下文变量）时，我们也必须始终问：我们确定我们需要它们吗？ 我们不能只是显式地传递参数吗？ 有时，由于许多原因，这是不可行的。 但是，优先考虑显式性至少意味着提出问题并评估工作量。