Python 高手编程系列九百三十八 ：property

property 的名称使用小写或小写加下划线。大部分时候，它们表示一个对象的状态，
可以是名词或形容词，如果需要的话也可以是如下简短的短语：
class Connection:
_connected = []
def connect(self, user):
self._connected.append(user)
@property
def connected_people(self):
return ', '.join(self._connected)
在交互式会话中运行的结果如下所示：

connection = Connection()
connection.connect(‘Tarek’)

connection.connect(‘Shannon’)
print(connection.connected_ _people)
Tarek, Shannon
类
类名称始终采用驼峰式命名法，如果它们是模块的私有类，还可能有一个前缀下划线。
类和实例变量通常是名词短语，与用动词短语命名的方法名称构成使用逻辑：
class Database:
def open(self):
pass
class User:
pass
下面是在交互式会话中的使用示例：
user = User()
db = Database()
db.open()
模块和包
除了特殊模块__init__之外，模块名称都使用小写，不带下划线。
下面是标准库中的一些例子：
• os；
• sys；
• shutil。
如果模块是包的私有模块，则添加一个前缀下划线。编译过的 C 或 C++模块名称通常
带有一个下划线，并在纯 Python 模块中导入。
包名称遵循同样的规则，因为它的表现就像是更加结构化的模块。
命名指南
一组常用的命名规则可以被应用于变量、方法、函数和 property。类和模块的名称
也在命名空间的构建中具有重要的作用，从而也影响代码可读性。本迷你指南为挑选名称
提供了常见的模式和反模式。
用“has”或“is”前缀命名布尔元素
如果一个元素保存的是布尔值，is 和 has 前缀提供一种自然的方式，使其在命名空
间中的可读性更强，代码如下：
class DB:
is_connected = False
has_cache = False
用复数形式命名集合变量
如果一个元素保存的是集合变量，那么使用复数形式是一个好主意。有些映射在暴露
为序列时也可以从中受益：
class DB:
connected_users = [‘Tarek’]
tables = {
‘Customer’: [‘id’, ‘first_name’, ‘last_name’]
}
用显式名称命名字典
如果一个变量保存的是映射，那么你应该尽可能使用显式名称。例如，如果一个字典
保存的是个人地址，那么可以将其命名为 persons_addresses，代码如下：
persons_addresses = {‘Bill’: ‘6565 Monty Road’,
‘Pamela’: ‘45 Python street’}
persons_addresses[‘Pamela’]
‘45 Python street’
避免通用名称
如果你的代码不是在构建一种新的抽象数据类型，那么使用类似 list、dict、
sequence 或 elements 等专用名词是有害的，即使对于局部变量也一样。它使得代码难
以阅读、理解和使用。还应该避免使用内置名称，以避免在当前命名空间中将其屏蔽
（shadowing）。还应该避免使用通用的动词，除非它们在该命名空间中有意义。
相反，应该使用领域特定的术语，如下所示：
def compute(data): # 太过通用
for element in data:
yield element ** 2
def squares(numbers): # 更好一些
for number in numbers:
yield number ** 2
还有一系列前缀和后缀，虽然在编程中非常常见，但事实上应该避免出现在函数和类
名称中：
• manager；
• object；
• do、handle 或 perform。
这样做的原因是它们的含义模糊、模棱两可，且没有向实际名称中添加任何信息。Jeff
Atwood（Discourse 和Stack Overflow 的联合创始人）关于这个话题写过一篇非常好的文章，你
可以在他的博客上找到这篇文章：http://blog.codinghorror.com/i-shall-call-it-somethingmanager/。
还有许多包的名称应该避免。任何没有对其内容给出任何信息的名称，从长远来看都对项
目有很大害处。诸如misc、tools、utils、common 或core 的名称有很大可能会变成一大
堆不相关的、质量非常差的代码片段，其大小呈指数增长。在大多数情况下，这种模块的存在是
懒惰或缺乏足够设计经验的迹象。热衷于这种模块名称的人可以预见未来，并将其重命名为
trash（垃圾箱）或dumpster（垃圾桶），因为这正是他们的队友最终对这些模块的处理方式。
在大多数情况下，更多的小模块几乎总是更好，即使内容很少，但名称可以很好地反
映其内容。说实话，类似 utils 和 common 之类的名称没有本质错误，你可以负责任地使
用它们。但现实表明，在许多情况下，它们都会变为危险的结构反模式，并且迅速增长。
而且如果你的行动不够快，你可能永远无法摆脱它们。因此，最好的方法就是避免这样有
风险的组织模式，如果项目其他人引入的话则将其扼杀在萌芽状态。