警告！你的Python代码命名太烂了，命令你熟读本篇迷你命名指南！
- 2019 年 11 月 11 日
- 筆記
大家好，我是 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 编码风格，使它已经成为了事实上的代码风格标准。
这个我曾经写了一篇文章专门介绍过了，有兴趣的可以看一下：
