爱站程序员基地一、代码规范的意义
代码规范，这词可能在很多人感觉是熟悉又陌生。熟悉的是，好像经常能在网上博文里看到这样的字眼。陌生的是自己在撸代码的时候好像没怎么思考过这个问题。
我虽在写代码的时候会带着注意规范，但也不是完全谨遵规范来的，因为我也不知道到底有多少规范，哈哈。话虽如此，代码规范的重要性还是非常大的，不然阿里这样的也就不用出个手册来规范员工的代码了。
那为什么要去强调代码规范呢？
我觉得最大的意义是易于阅读。不光是别人阅读，过段时间你自己看自己代码的时候，也不至于要想上半天。其实仔细想想，咱们的日常编码工作中，阅读代码的时间应该是多于敲代码的时间的。
很多时候，我们指尖飞舞，一顿操作猛如虎，结果运行就出问题了，然后一行行的开始debug半天。如果你的代码阅读性差，估计你自己都看不下去了吧。(别问我是怎么知道的)
二、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 Falsereturn 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-likeobject 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互相关联
四、写在最后
上面列的虽然比较多，但是也别害怕，仔细理解下，上述这些规范最终目的就是一个：提高代码阅读性，你写代码的时候也带点心就好了，毕竟没有什么事情是绝对的，万事都有个度在里面，自己权衡好。
