警告！你的Python代码命名太烂了，命令你熟读本篇迷你命名指南！

大家好，我是 Rocky0429，一个最近老在写代码的蒟蒻...

夜路走多了，总会遇到鬼，代码写多了，难免遇到 bug...

刚开始我丝毫不慌，祭出我的 debug 两板斧，小小 bug 何足挂齿，看我分分钟解决你！

就这样分分分分分分分分分分钟后：bug 太强，不能匹敌，开始撤退！

所以我只能求助大佬，帮我调试一波，就在我美滋滋的等着我的 bug 被大佬砍瓜切菜的时候，我的微信响起来了...

呵，大佬也有宕机的时候，命名是我命的，你说是不是人写的？？还有我老师真的没有教我命名规范阿...

不就是命名规范么？我马上学起来！等我学成了还找你给我调 bug ！

"迷你"命名指南

为了防止我亲爱的读者不再重复我的老路，我决定挑选一些具有普适性的命名规则，可以应用在变量、函数、类、模块等命名上面．

实际上的命名规则千千万，没必要都记清楚，掌握其中一些重要的，足够你理直气壮的让大佬去调 bug...

0x00 拒绝通用词

1、写代码的时候，不管是全局变量还是局部变量，都应该避免使用 'list'、'dict'、'elements' 等词作为变量名，它们会使代码变的难以阅读、理解。

2、像 'abs'、'str'、'eval' 等内置函数也应该避免使用，防止出现在当前命名空间中被屏蔽的尴尬情况。

3、一些列的前缀和后缀。虽然在编程中非常常见，但事实上应该避免出现在函数和类名称中，比如 'object'、'handle'、'do' 等词，这样做的原因是它们的含义模糊，摸棱两可，并且没有向实际名称中添加任何信息。

4、许多包的名称都应该被避免，诸如 'tools'、'utils'、'core' 的名称很大可能会变成一大堆不相关的、质量非常差的代码片段，虽然它们在名称上并没有本质的错误，但为了防止问题的出现，还是直接将其作为自己自定义包的命名扼杀在萌芽状态为好。

0x01 使用专业术语

这个算是 0x00 的延申，拒绝通用词，相反的使用特定领域特定的专业术语，比如下面的代码：

def calculation(datas):
    for data in datas:
        yield data ** 2

这部分代码的命名就有些问题，比如函数名 calculation 是计算的意思，计算分很多种，到底计算什么呢？这样很不直观，如果是换成下面这样：

def squares(numbers):
    for number in numbers
        yield number ** 2

这种的命名就比第一种清晰明了很多。

0x02 用 'has' 或 'is' 前缀命名 bool 元素

对于保存布尔值的变量，对其命名的时候将 'has' 或 'is' 作为其前缀，可以使它们在代码中的可读性更强：

is_succeed = True
has_cache = False

0x03 避免出现上下文中已存在的名称

不要在代码中继续使用已经存在的名称，这会在阅读代码的时候非常令人疑惑，尤其是在出现 bug 进行单步调试的时候，更是令人抓狂！比如像下面这样：

import os

def squares(numbers):
    for os in numbers:
        yield os ** 2

上面这个例子中，如果你再使用 os 模块做其它事情，可能会没什么效果。还是那句话，内置函数名和标准库的模块名都应该被避免。

0x04 集合变量用复数形式命名

如果一个元素是集合变量，那么使用复数形式是一个很好的办法，比如像下面这样：

users = ['Rocky', 'leey']

0x05 以 key - value 命名字典名

对于字典来说，它保存的是一个映射关系的数据，那我们命名就尽量以映射的双方来命名，也就是 key 含义 - value 含义，比如：一个字典保存的是学生的成绩，那么可以将它命名为 'students_scores'：

students_scores = {
    'Rocky': 100,
    'leey': 60
}

0x06 模块和包的命名

模块和包的命名应该体现其表达的内容，它们的名称应该简短，应该使用小写字母并且不带下划线，同样还要始终避免与标准库模块相同的名称。

0x07 代码风格

Python 官方给出了一种编码规范 PEP 8，当然这个只是个标准而已，并没有强制要求大家都要去遵守，但又好像大多数人都使用了 PEP 8 编码风格，使它已经成为了事实上的代码风格标准。

这个我曾经写了一篇文章专门介绍过了，有兴趣的可以看一下：

如何写出符合 Python 审美的代码风格？