【python】聊聊容易被忽视的“代码规范” - 把苹果咬哭的测试笔记

二、pycharm中的辅助提示

得益于现在代码编辑器的强大，在pycharm中就可以设置规范帮你检查代码。

这里的PEP 是 Python Enhancement Proposal 的缩写，翻译过来叫“Python 增强规范”，当它检测到有不符合规范
的代码是就会给出建议提示。我觉得越是新手，越早点了解并且尽量遵循规范是最好的。因为你规范的敲代码并不会比
你乱敲慢太多，从新手就养成好习惯，可比你以后再改过来容易多了。

成，那么在python里，又有哪些规范是需要我们在意的呢？

三、常用规范

1、缩进：

使用四空格缩进，不要使用tab，也不要混合着使用。

每行最大长度尽量控制79个字符内，不然单行太长也不利于阅读。
此外，当你写嵌套代码的时候，如果层数多了，很容易就超过这个长度限制了。其实也变相提醒着我们，
代码不要迭代的太深入，要善于拆分代码来优化代码结构。

2、空格：

函数的参数之间要有一个空格，跟写英语一样，不然挤在一起多闹心。

字典的冒号之后要有一个空格

列表、元组、字典的元素之间要有一个空格

使用#注释的话，#后要有一个空格

操作符(比如+，-，*，/，&，|，=，==，!=)两边都要有一个空格，不过括号(包括小括号、中括号和大括号)内的两端不需要空格

3、空行：

全局的(文件级别的)类和全局的函数上方要有两个空行

类中的函数上方要有一个空行

函数内部不同意义的代码块之间可以有一个空行

不要把多行语句合并为一行(即不要使用分号分隔多条语句)

当使用控制语句if/while/for时，即使执行语句只有一行命令，也需要另起一行

代码文件尾部有且只有一个空行，不要敲多

4、换行：

通过小括号进行封装，此时虽然跨行，但是仍处于一个逻辑引用之下。比如函数参数列表的场景、过长的运算语句场景

def fit(self,
        x=None,
        y=None,
        batch_size=None,
        epochs=1,
        verbose=1,
        callbacks=None,
        validation_split=0.,
        validation_freq=1,
        max_queue_size=10,
        workers=1,
        use_multiprocessing=False,
        **kwargs):
直接通过换行符()实现
5、导包：
所有import尽量放在代码文件的头部位置
每行import只导入一个对象
当使用from xx import xx时，import后面跟着的对象要是一个package(包对应代码目录)或者module(模块对应代码文件)，不要是一个类或者一个函数
6、注释：
对于代码块注释，在代码块上一行的相同缩进处以 # 开始书写注释
代码行注释，在代码行的尾部跟2个空格，然后以 # 开始书写注释，行注释尽量少写
# 对于代码块注释，在代码块上一行的相同缩进处以 # 开始书写注释
# 文字多就多写几行，当文章一样，一定要注意逻辑别写错
def solve(x):
    if x == 1:  # 单行注释在尾部跟2个空格，然后以 # 开始书写注释，行注释尽量少写
        return False
    return True
如果写英文注释开头要大写，结尾要写标点符号，避免语法错误和逻辑错误。
改动代码逻辑时，一定要及时更新相关的注释
7、文档描述：
格式：三个双引号开始、三个双引号结尾；

注意点：首先用一句话简单说明这个函数做什么，然后跟一段话来详细解释；

再往后是参数列表、参数格式、返回值格式的描述。
# 参考下requests库中post方法的描述
def post(url, data=None, json=None, **kwargs):
    r"""Sends a POST request.
    :param url: URL for the new :class:`Request` object.
    :param data: (optional) Dictionary, list of tuples, bytes, or file-like
        object to send in the body of the :class:`Request`.
    :param json: (optional) json data to send in the body of the :class:`Request`.
    :param \*\*kwargs: Optional arguments that ``request`` takes.
    :return: :class:`Response <Response>` object
    :rtype: requests.Response
    return request('post', url, data=data, json=json, **kwargs)
8、命名：
变量名，要全部小写，多个词通过下划线连接，比如data_format
有时候可以使用单字符变量名，比如for i in range(n)这种变量没有实际意义的情况
类的私有变量名，变量名前需要加2个下划线，比如__description__
常量名，要全部大写，多个词通过下划线连接，比如WAIT_TIME
函数名，要全部小写，多个词通过下划线连接，比如check_input_validation()
类名，要求驼峰形式，即单词首字母大写，多个词的话，每个词首字母大写然后直接拼接，比如class FeatureSet()
命名需要做到名如其意，不要过于吝啬名字的长度，比如test_allot_list_query_by_status()，通过状态查询列表
9、注意代码分解：
不写重复代码，重复代码可以通过使用条件、循环、函数和类来解决
减少迭代层数，让代码扁平化
函数拆分，函数的粒度尽可能细，也就是一个函数不要做太多事情
类的拆分，如果一个类中有多个属性描述的是同一类事物，就可以把这些属性拆分出来新建一个单独的类
模块化，若项目偏大，要为不同功能模块创建独立的目录或文件，通过import互相关联
四、写在最后
上面列的虽然比较多，但是也别害怕，仔细理解下，上述这些规范最终目的就是一个：提高代码阅读性，你写代码的时候也带点心

就好了，毕竟没有什么事情是绝对的，万事都有个度在里面，自己权衡好。
    --不要用肉体的勤奋，去掩盖思考的懒惰--