python变量命名
Steven迪文 人气:01.变量命名
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 准则。
漂亮总比难看好。
显性比隐性好。
简单比复杂好。
复杂比复杂好。
平的比嵌套的好。
疏比密好。
可读性。
特殊情况并不特别到足以打破规则。
尽管实用性胜过纯洁。
错误不应该悄无声息地过去。
除非显式地沉默。
面对模棱两可,拒绝猜测的诱惑。
应该有一种——最好只有一种——明显的方法来做这件事。
除非你是荷兰人,否则这种方式一开始可能并不明显。
现在做总比不做好。
虽然永远不做总是比现在好。
如果实现很难解释,那就不是一个好主意。
如果实现易于解释,那么它可能是个好主意。
加载全部内容