今天给大家分享35条大佬对改善Python程序的建议
建议1、理解Pythonic概念----详见Python中的《Python之禅》
建议2、编写Pythonic代码
(1)避免不规范代码,比如只用大小写区分变量、使用容易混淆的变量名、害怕过长变量名等。有时候长的变量名会使代码更加具有可读性。
(2)深入学习Python相关知识,比如语言特性、库特性等,比如Python演变过程等。深入学习一两个业内公认的Pythonic的代码库,比如Flask等。
建议3:理解Python与C的不同之处,比如缩进与{},单引号双引号,三元操作符?,Switch-Case语句等。
建议4:在代码中适当添加注释
建议5:适当添加空行使代码布局更加合理
建议6:编写函数的4个原则
(1)函数设计要尽量短小,嵌套层次不宜过深
(2)函数声明应该做到合理、简单、易用
(3)函数参数设计应该考虑向下兼容
(4)一个函数只做一件事,尽量保证函数粒度的一致性
建议7:将常量集中在一个文件,且常量名尽量使用全大写字母
建议8:利用assert语句来发现问题,但要注意,断言assert会影响效率
建议9:数据交换值时不推荐使用临时变量,而是直接a, b = b, a
建议10:充分利用惰性计算(Lazy evaluation)的特性,从而避免不必要的计算
建议11:理解枚举替代实现的缺陷(最新版Python中已经加入了枚举特性)
建议12:不推荐使用type来进行类型检查,因为有些时候type的结果并不一定可靠。如果有需求,建议使用isinstance函数来代替
建议13:尽量将变量转化为浮点类型后再做除法(Python3以后不用考虑)
建议14:警惕eval()函数的安全漏洞,有点类似于SQL注入
建议15:使用enumerate()同时获取序列迭代的索引和值
建议16:分清==和is的适用场景,特别是在比较字符串等不可变类型变量时(详见评论)
建议17:尽量使用Unicode。在Python2中编码是很让人头痛的一件事,但Python3就不用过多考虑了
建议18:构建合理的包层次来管理Module
建议19:有节制的使用from...import语句,防止污染命名空间
建议20:优先使用absolute import来导入模块(Python3中已经移除了relative import)
建议21:i+=1不等于++i,在Python中,++i前边的加号仅表示正,不表示操作
建议22:习惯使用with自动关闭资源,特别是在文件读写中
建议23:使用else子句简化循环(异常处理)
建议24:遵循异常处理的几点基本原则
(1)注意异常的粒度,try块中尽量少写代码
(2)谨慎使用单独的except语句,或except Exception语句,而是定位到具体异常
(3)注意异常捕获的顺序,在合适的层次处理异常
(4)使用更加友好的异常信息,遵守异常参数的规范
建议25:避免finally中可能发生的陷阱
建议26:深入理解None,正确判断对象是否为空。Python中下列数据会判断为空:
建议27:连接字符串应优先使用join函数,而不是+操作
建议28:格式化字符串时尽量使用.format函数,而不是%形式
建议29:区别对待可变对象和不可变对象,特别是作为函数参数时
建议30:[], {}和():一致的容器初始化形式。使用列表解析可以使代码更清晰,同时效率更高
建议31:函数传参数,既不是传值也不是传引用,而是传对象或者说对象的引用
建议32:警惕默认参数潜在的问题,特别是当默认参数为可变对象时
建议33:函数中慎用变长参数*args和**kargs
(1)这种使用太灵活,从而使得函数签名不够清晰,可读性较差
(2)如果因为函数参数过多而是用变长参数简化函数定义,那么一般该函数可以重构
建议34:深入理解str()和repr()的区别
(1)两者之间的目标不同:str主要面向客户,其目的是可读性,返回形式为用户友好性和可读性都比较高的字符串形式;而repr是面向Python解释器或者说Python开发人员,其目的是准确性,其返回值表示Python解释器内部的定义
(2)在解释器中直接输入变量,默认调用repr函数,而print(var)默认调用str函数
(3)repr函数的返回值一般可以用eval函数来还原对象
(4)两者分别调用对象的内建函数__str__()和__repr__()
建议35:分清静态方法staticmethod和类方法classmethod的使用场景
更多Python视频、源码、资料加群683380553免费获取