位置：首页-资讯-后端开发

python中的变量命名规则详情

2024-04-02 19:55

短信预约 -IT技能 免费直播动态提醒

1.变量命名

1）命名的规范性

变量名可以包括字母、数字、下划线，但是数字不能做为开头。

系统关键字不能做变量名使用

除了下划线之个，其它符号不能做为变量名使用 !

Python的变量名是除分大小写的

2）编程语言常用驼峰命名法

大驼峰:每一个单词的首字母都大写 FirstName LastName
小驼峰:第一个单词以小写字母开始，后续单词的首字母大写 firstName lastName

但是在python中一般使用小驼峰加下划线的方式:

has_error
is_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 准则。

漂亮总比难看好。
显性比隐性好。
简单比复杂好。
复杂比复杂好。
平的比嵌套的好。
疏比密好。
可读性。
特殊情况并不特别到足以打破规则。
尽管实用性胜过纯洁。
错误不应该悄无声息地过去。
除非显式地沉默。
面对模棱两可，拒绝猜测的诱惑。
应该有一种——最好只有一种——明显的方法来做这件事。
除非你是荷兰人，否则这种方式一开始可能并不明显。
现在做总比不做好。
虽然永远不做总是比现在好。
如果实现很难解释，那就不是一个好主意。
如果实现易于解释，那么它可能是个好主意。