python中的变量命名规则详情
1.变量命名
1）命名的规范性
变量名可以包括字母、数字、下划线，但是数字不能做为开头。
系统关键字不能做变量名使用
除了下划线之个，其它符号不能做为变量名使用 !
Python的变量名是除分大小写的
2）编程语言常用驼峰命名法
- 大驼峰:每一个单词的首字母都大写
FirstName LastName - 小驼峰:第一个单词以小写字母开始，后续单词的首字母大写
firstName lastName
但是在python中一般使用小驼峰加下划线的方式:
has_erroris_person
2. 变量命名的描述性
在接受范围内，变量名所描述的内容越精准越好。
- BAD: day, host, cards, temp
- GOOD: day_of_week, hosts_to_reboot, expired_cards
变量名能让人猜出类型。
例如: Bool 类型
is_user : 是否是用户
例如: int/float 类型
port：端口号age：年龄
这些很直观的能让人猜出类型。
注意： 不要使用复数来表示一个 int 类型变量，比如 apples，最好用 number_of_apples来替代。
3.变量名尽量短，但是不要太短
一个好的变量名，长度应该控制在两到三个单词左右
例如:person_index
同一段代码内不要使用过于相似的变量名，比如同时出现 users、users1、 user3。
不要使用带否定含义的变量名，用is_special 代替is_not_normal。
4.合理使用变量
同一个变量名指代的变量类型，也需要保持一致性。
在一个函数中，一个变量名叫做 photo, 那么在其他地方就不要改成image。
5. 变量定义尽量靠近使用
刚开始学习编程时，我们习惯把定义的变量放在开头，或一些函数最前面。
如下:
def get_name(): students = [] teachers = []
这样的方式虽然看起来很简洁，但是对代码可读性没有帮助，更好的做法是，让变量定义尽量靠近使用。
6. 合理使用namedtuple/dict
Python中的函数可以返回多个值，如果某一天我们想让函数再多返回一个值怎么办呢？
#之前 def get_name(): return student, teacher #现在 def get_name(): return student, teacher, parent
namedtuple/dict 此时可以派上用场
#1. 使用dict
def get_name():
return {
'student': student,
'teacher':teacher,
'parent' :parent
}
names_dict = get_name()
# 2. 使用 namedtuple
from collections import namedtuple
Names = namedtuple("Names", ['student', 'teacher', 'parent'])
def get_name():
return Names(
student = student,
teacher = teacher,
parent = parent
)
names = get_name()
但是这样不能像之前一样，每一次解包多变量接受函数返回值。
6. 控制单个函数内的变量数量
当某一函数过长时，或者包含太多变量时，请及时把它拆分成多个小函数。
7. 删除掉没用的变量
在一个函数中，如果某一个定义的变量没有被用到，请及时删除它。
8. 定义临时变量提高可读性
if student.is_active and (student.sex == 'female'): student.add_tolist() return #把上面的例子变成如下 student_is_eligible = student.is_active and (student.sex == 'female') if student_is_eligible: student.add_tolist() return
需要合理运用临时定义对象，把不必要的东西赋值成临时变量反而会让代码显得啰嗦！
9. The Zen of Python
最后分享一下 Zen of Python 准则。
漂亮总比难看好。
显性比隐性好。
简单比复杂好。
复杂比复杂好。
平的比嵌套的好。
疏比密好。
可读性。
特殊情况并不特别到足以打破规则。
尽管实用性胜过纯洁。
错误不应该悄无声息地过去。
除非显式地沉默。
面对模棱两可，拒绝猜测的诱惑。
应该有一种——最好只有一种——明显的方法来做这件事。
除非你是荷兰人，否则这种方式一开始可能并不明显。
现在做总比不做好。
虽然永远不做总是比现在好。
如果实现很难解释，那就不是一个好主意。
如果实现易于解释，那么它可能是个好主意。
