【python】聊聊容易被忽视的“代码规范”

一、代码规范的意义

代码规范，这词可能在很多人感觉是熟悉又陌生。
熟悉的是，好像经常能在网上博文里看到这样的字眼。陌生的是自己在撸代码的时候好像没怎么思考过这个问题。

我虽在写代码的时候会带着注意规范，但也不是完全谨遵规范来的，因为我也不知道到底有多少规范，哈哈。
话虽如此，代码规范的重要性还是非常大的，不然阿里这样的也就不用出个手册来规范员工的代码了。

那为什么要去强调代码规范呢？

我觉得最大的意义是易于阅读。不光是别人阅读，过段时间你自己看自己代码的时候，也不至于要想上半天。
其实仔细想想，咱们的日常编码工作中，阅读代码的时间应该是多于敲代码的时间的。

很多时候，我们指尖飞舞，一顿操作猛如虎，结果运行就出问题了，然后一行行的开始debug半天。如果你的
代码阅读性差，估计你自己都看不下去了吧。(别问我是怎么知道的)

二、pycharm中的辅助提示

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

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

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

三、常用规范

1、缩进：

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

2、空格：

1. 函数的参数之间要有一个空格，跟写英语一样，不然挤在一起多闹心。
2. 字典的冒号之后要有一个空格
3. 列表、元组、字典的元素之间要有一个空格
4. 使用#注释的话，#后要有一个空格
5. 操作符(比如+，-，*，/，&，|，=，==，!=)两边都要有一个空格，不过括号(包括小括号、中括号和大括号)内的两端不需要空格

3、空行：

1. 全局的(文件级别的)类和全局的函数上方要有两个空行
2. 类中的函数上方要有一个空行
3. 函数内部不同意义的代码块之间可以有一个空行
4. 不要把多行语句合并为一行(即不要使用分号分隔多条语句)
5. 当使用控制语句if/while/for时，即使执行语句只有一行命令，也需要另起一行
6. 代码文件尾部有且只有一个空行，不要敲多

4、换行：

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

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):

2. 直接通过换行符()实现

5、导包：

1. 所有import尽量放在代码文件的头部位置
2. 每行import只导入一个对象
3. 当使用from xx import xx时，import后面跟着的对象要是一个package(包对应代码目录)或者module(模块对应代码文件)，不要是一个类或者一个函数

6、注释：

1. 对于代码块注释，在代码块上一行的相同缩进处以 # 开始书写注释
2. 代码行注释，在代码行的尾部跟2个空格，然后以 # 开始书写注释，行注释尽量少写

# 对于代码块注释，在代码块上一行的相同缩进处以 # 开始书写注释
# 文字多就多写几行，当文章一样，一定要注意逻辑别写错
def solve(x):
    if x == 1:  # 单行注释在尾部跟2个空格，然后以 # 开始书写注释，行注释尽量少写
        return False
    return True

3. 如果写英文注释开头要大写，结尾要写标点符号，避免语法错误和逻辑错误。
4. 改动代码逻辑时，一定要及时更新相关的注释

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、命名：

1. 变量名，要全部小写，多个词通过下划线连接，比如data_format
2. 有时候可以使用单字符变量名，比如for i in range(n)这种变量没有实际意义的情况
3. 类的私有变量名，变量名前需要加2个下划线，比如__description__
4. 常量名，要全部大写，多个词通过下划线连接，比如WAIT_TIME
5. 函数名，要全部小写，多个词通过下划线连接，比如check_input_validation()
6. 类名，要求驼峰形式，即单词首字母大写，多个词的话，每个词首字母大写然后直接拼接，比如class FeatureSet()
7. 命名需要做到名如其意，不要过于吝啬名字的长度，比如test_allot_list_query_by_status()，通过状态查询列表

9、注意代码分解：

1. 不写重复代码，重复代码可以通过使用条件、循环、函数和类来解决
2. 减少迭代层数，让代码扁平化
3. 函数拆分，函数的粒度尽可能细，也就是一个函数不要做太多事情
4. 类的拆分，如果一个类中有多个属性描述的是同一类事物，就可以把这些属性拆分出来新建一个单独的类
5. 模块化，若项目偏大，要为不同功能模块创建独立的目录或文件，通过import互相关联

四、写在最后

上面列的虽然比较多，但是也别害怕，仔细理解下，上述这些规范最终目的就是一个：提高代码阅读性，你写代码的时候也带点心
就好了，毕竟没有什么事情是绝对的，万事都有个度在里面，自己权衡好。