Python思维导图：
//app.siweidaotu.com/#R0652402e50522cf245e39f060f811bdd
介绍
-
Python创始人: Guido（吉多·范罗苏姆），出版过《Python风格指南》
-
开发背景：提高组内自动化开发效率，避免重复开发，对组内各模块已开发的自动化 lib 库、
case中常用的操作、以及其他工具的调用接口进行汇总，管理出 dspa 组内自动化case开发的基础库。
-
语言：采用二进制工具进行编译。
-
规范文档
为了方便维护、他人阅读使用，整理出该编码规范文档。请大家开发时遵循本规范进行开发。
-
This document was adapted from Guido’s original Python Style Guido essay[2],with some additins from barry’s style guide[5]. Where there’s conflict, Guido’s style rules for the purposes of this PEP. This PEP may still be incomplete(in face, it may never be finished).
本文档改编自Guido的最初的《Python风格指南》一文，并添加了一些来自《Barry‘s style guide》的风格指南[5]。在有冲突的地方，Guido的风格规则应该是符合本PEP的意图。这篇PEP也许仍然尚未完成(实际上，它可能永远不会结束)。
代码布局
-
Tab键还是用空格缩进
Python里有 “用空格为荣，Tab为耻”，全用空格确实麻烦，所以这里不限定使用tab，可以全用tab也不会报错，切记不能混用。
-
行的长度：推荐长度在72个字节内，使用反斜杠'/'续行
-
空行
用两行分割顶层函数和类的定义。
-
编码：UTF-8才是王道，#coding=utf-8为标准格式
-
导入
import 模块名，import 模块名 as 别名， from 模块名 import 具体函数;应该使用单行导入一个模块，不能导入两个import 模1，模2，除非from 模块 import 函数1,函数2这样就可以
模块导入顺序
-
Python内置模块
-
第三方库(使用pip 安装的库)
-
自定义的库
并且每组的import用空行分割
空格
-
以下地方不推荐使用空格
- 紧挨着圆括号，方括号和花括号。
如：span( name [ 1 ] , { a : 1 } )改成：span(name[1], {a: 1})
- 紧贴在逗号、分号、冒号前的空格都得去掉
如：if x == 1 : x , y : x , y = y , x 改成: if x == 1: x, y: x, y = y, x
- 紧贴着函数调用的参数列表前[]括号前的空格得去掉
如：dict ['key'] = list [ 1 ]改成 dict['key'] = list[1]
- 紧贴在索引或切片下标开始的[]括号前的空格去掉
如：dict ['key'] = list [ 1 ]改成 dict['key'] = list[1]
- 只能在赋值或其他运算符的符号两端用空格
1: x = 1
2: y = 2
3: z = 3
----------------------
改成：
1: x = 1
2: y = 2
3: z = 3
其他建议：
始终在这些二元运算符两边放置一个空格：赋值（=），比较（==,<,>,!=,<>,<=,>=,in,）
在算术运算符两端插入空格，使保持二元运算符两边空格保持一致。
×： a = 1+2
×： a = 1*2 + 3
√： a = 1 + 2
√： a = 1 * 2 + 3
不要用于指定关键字参数或默认参数值的“=”号两端使用空格，例如：
×： Foo(name = '林青霞', age = 23)
√： Foo(name='林青霞', age=23)
不要将多行语句写在一行上，虽然能够运行，但是代码不规范不建议使用。
×： if x == 1: print('不规范')
√： if x == 1:
print('规范写法，建议使用')
注释
注释必须跟代码保持一致，修改代码时，建议先修改注释。
注释必须是完整的句子。
如果注释是一个句子或者短语，首字母必须大写。
如果注释很短，建议省略句末的句号。
注释块通常由一个或多个由完整句子构成的段落组成，每个句子应该以句号结尾。
注释请使用英文。
约定使用同一的文档化注释格式有助于良好的习惯和团队的进步。
注释块
多行注释前后空一行，并且保持注释标识在同一层次下，提高代码阅读性。
注释块中每行以’#'和一个空格开始（除非他是注释内的缩进文本）。
命名风格
注意点：
-
单下划线作为前导，如：_single_begin, 这是弱的内部使用标识，
例如使用“from M import *”的时候不会导入；
-
单下划线作为结尾的，如：single_end_，这一般用于跟python关键词冲突。
-
双下划线前导，如：__double_begin，类私有名；
-
双下换线前导+结尾，如：__double_begin_and_and_，特殊对象或属性，存在于用户控制的命名空间中，如：__init__，__import__等。有时可以被用户定义，用于触发某个特殊行为，称为运算符重载。
应避免的名字
永远不要用：
- 小写字母“l”（小写的“L”）
- 大写字母
“O”
- 大写字母“I”（大写字母“i”）
作为单字符的变量名，因为不利于跟数字“O”和“1”很好的区分开。
当要用小写字母“l”时，请用大写字母“L”代替。
模块名
模块应该是不含下划线的，简短的，小写的名字。
因为模块名被映射到文件名，有些文件系统大小写不敏感并且截短长名称，模块名被选为相当短是重要的—这在Linux上不是问题，但当代码传到Mac或Windows上就可能是个问题了。
类名
类名总是使用并遵守首字母大写、驼峰式写法的约定。
异常名
首字母大写、驼峰式写法
全局变量名
这个约定跟函数的约定差不多。
不想被导入的全局变量（还有内部函数和类）前面加一个下划线。
函数名
函数名应该小写、动宾短语，可能用下划线风格单词，这样可以增加可读性。如：open_file()
方法名和实例变量名
小写、动宾短语、下划线风格可以增加可读性。
单前导下划线仅用于不打算作为类的公共接口的内部方法。
双前导下划线表示“类私有的名字”，python把这些名字和类名连接在一起。
如果类Foo有一个属性名为 __a，它不能以 Foo.__a 访问，如果非要用到，可以通过
Foo.Foo_a 得到访问权。通常，双前导下划线应该只用来避免与类中的属性发生名字冲突。
设计建议
-
**与像None之类的单值进行比较，应该使用：“is”或“is not”**
当你本意是“if x is not None”时，对写成“if x”要小心，因为例如当你测试一个默认为None的变量或参数是否被设置为其他值时，这个其他值可能是一个布尔上下文中为假的值。
-
基于类的异常总是好过基于字符串的异常：
模块和包应该定义它们自己的异常类，基类应该是内建的 Exception 类的子类。始终包含一个类的文档字符串。例如:
class MessageError(Exception):
"""Base Class for error in the email package."""
-
使用字符串方法代替字符串模块
因为字符串方法是非常的块。
-
在检查前缀或后缀时避免对字符串进行切片
用 startswith() 和 endswith() 代替，因为他们更明确且错误更少，例：
×： if foo[:3] == "bar":
√： if foo.startswith('bar'):
-
对象类型的比较应该使用 isinstance() 代替直接比较类型。例：
×： if type(obj) is type(1):
√： if isinstance(obj, 类型
-
检查一个对象是否是字符串时，谨记它也可能是unicode字符串。
-
对序列（列表、元组、集合、字符串），判断空列表是否为false的事实，因此 if not seq 或 if seq 比 if len(seq) 或 if not len(seq) 好。
-
书写字符串时不要依赖于有意义的后置空格，这种后置空格在视觉上不易辨别。
-
No Chinese！包括注释，也请尽量使用英文。
-
自动化 case 中使用 python logging 模块设定日志级别打印日志，而不要大量使用 print 输出。
-
Print时使用 “%s”、“%d” 等标准输出格式，请勿 str 和变量混合连接使用。
>>> import this
Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!
