活动地址：CSDN21天学习挑战赛
前言：
Python的语法其实和其它的语言比如Java，PHP等等基本是一致的，只是Python可能会有一些自己的规则在里面，因此，Python不仅是一门简单易学的编程语言，也是一把能快速打开其它编程语言的钥匙。
正文：
一，Python之禅---初步认识Python的内涵
在任意的Python终端内写入 import this 将会看到Tim Peters写的Zen，其内容如下：
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!以上内容翻译如下：
优美漂亮的代码优于丑陋的代码。就是说我们不仅要求代码能够正常工作，而且还希望代码看起来优美。
•明确优于隐含。简单来说就是我们的代码要明确说明其用法，不要让用户根据他们自己的理解来猜。
•简单优于复杂。能用简单方法就一定不要故意给自己找麻烦，最简单的方法就是最好的方法。
•复杂胜于凌乱。如果功能很复杂，则希望能够将其分割成功能单一的多个模块；希望保持模块间接口函数简洁，保证各个模块功能单一。
•扁平优于嵌套。就是尽量不要使用嵌套，毕竟嵌套代码在调试时，定位问题比较麻烦，不知道是在哪一层嵌套时出的问题。
•宽松优于紧凑。各个代码模块之间的联系要简单，不能过于依赖某些模块，不要不同模块之间的联系过于复杂而形成蜘蛛网状。
•代码可读性很重要。变量名、函数名、类名最好有明确的含义。注释也是很重要的，注释可以帮助我们和他人来理解代码。
•即便是特例，也不可违背上述规则。所谓的特例就是这样一些情况，如果我们不遵守这些规则，看起来在目前更加划算。但是如果我们的代码会长期服务于我们，那么遵守这些规则最终会让我们受益。
•虽然现实往往不那么完美，但是不应该放过任何异常。对异常的处理非常重要，90%的问题就发生在那些边角用例中。
•对异常处理不可马虎。虽然多数异常出现概率很低，但是我们不能掉以轻心，希望能够找到异常发生的原因并将其解决，不能使用except捕捉到异常然后就不管了。
•如果存在多种可能，不要猜测。肯定有一种，通常也是唯一一种最佳的解决方案。
•对待代码，要有精益求精的精神，逐步改进，让其趋于完美。
•虽然这并不容易，因为你不是Python之父。完全按照上面执行，最开始可能有点困难，但是坚持下来，事情会变得容易起来。
•动手比不动手要好。编程既是脑力劳动，也是体力劳动。多多练习，将想法付之实践能够帮助我们更好地理解代码的优缺点。
•不假思索就动手还不如不做。动手之前，需要思考，确定目标，了解现状。比如，我们要完成的功能是否有类似的库可以使用，它们能否满足我们的需要，即使不能完全满足我们的需要，但可以看看有哪些设计思想值得我们借鉴。
•如果你的方案很难懂，那肯定是一个糟糕的方案。一个难懂的方案，一般很难实现，毕竟代码还是要人来写的。如果编写代码的人对这个方案的理解都不好，结果会和期望值相去甚远，毕竟差之毫厘谬以千里。
•如果你的方案很好懂，那肯定是一个好方案。如果一个方案很好懂，在方案论证时大家都能很好地理解，也能帮忙出主意。在开发时，开发人员也容易保证开发的进度和质量，测试方案和实施也要容易得多。最后出来一个爆款是大概率事件，大家都能从中受益。
•命名空间非常有用，我们应当多加利用。尽量不要将太多的东西放在一个包中，这样会导致功能不清，就像杂货铺一样。应该尽量将代码按照某种方式有效地组织起来。
虽然有这么一句彩虹屁，但这个Zen的整体理念是对的：
Although that way may not be obvious at first unless you're Dutch.以上其实也不只Python语言可用，其实，其它的语言也可套用，总结来说，代码编程时优雅永不过时，简洁，易读，结构合理，变量定义，函数定义，类定义等等有明确的含义（其实还是易读），结构不要太复杂（多层嵌套会增加逻辑上的阅读困难，其实也还是易读），逻辑清晰，完整。
以上要求是对于一个好的码农的要求（培养一个良好的编程习惯是长期的事情，也是一个良好的开端，万事开头对了，那么，你后面的事情应该都会正确的）。（有时候，我也会回看一些我自己写的代码，如果非要我给出一个感受，那么，我想说，确实有一些代码写的跟屎一样难看。哈哈）
二，
PEP8编程规范
PEP8规范是什么？
PEP是Python Enhancement Proposal的缩写，通常翻译为“Python增强提案”。
每个PEP都是一份为Python社区提供的指导Python往更好的方向发展的技术文档，其中的第8号增强提案（PEP 8）是针对Python语言编订的代码风格指南。
尽管我们可以在保证语法没有问题的前提下随意书写Python代码，但是在实际开发中，采用一致的风格书写出可读性强的代码是每个专业的程序员应该做到的事情，也是每个公司的编程规范中会提出的要求，这些在多人协作开发一个项目（团队开发）的时候显得尤为重要。
PEP8规范相关内容
我们可以从Python官方网站的PEP 8链接中找到该文档，下面我们对该文档的关键部分做一个简单的总结。
2.1 空格的使用
#1、使用空格来表示缩进而不要用制表符（Tab）。这一点对习惯了其他编程语言的人来说简直觉得不可理喻，因为绝大多数的程序员都会用Tab来表示缩进，但是要知道Python并没有像C/C++或Java那样的用花括号来构造一个代码块的语法，在Python中分支和循环结构都使用缩进来表示哪些代码属于同一个级别，鉴于此Python代码对缩进以及缩进宽度的依赖比其他很多语言都强得多。在不同的编辑器中，Tab的宽度可能是2、4或8个字符，甚至是其他更离谱的值，用Tab来表示缩进对Python代码来说可能是一场灾难。
#2、和语法相关的每一层缩进都用4个空格来表示。
#3、每行的字符数不要超过79个字符，如果表达式因太长而占据了多行，除了首行之外的其余各行都应该在正常的缩进宽度上再加上4个空格。
#4、函数和类的定义，代码前后都要用两个空行进行分隔。
#5、在同一个类中，各个方法之间应该用一个空行进行分隔。
#6、二元运算符的左右两侧应该保留一个空格，而且只要一个空格就好。
2.2 标识符命名
PEP 8倡导用不同的命名风格来命名Python中不同的标识符，以便在阅读代码时能够通过标识符的名称来确定该标识符在Python中扮演了怎样的角色（在这一点上，Python自己的内置模块以及某些第三方模块都做得并不是很好）。
#1、变量、函数和属性应该使用小写字母来拼写，如果有多个单词就使用下划线进行连接。
#2、类中受保护的实例属性，应该以一个下划线开头。
#3、类中私有的实例属性，应该以两个下划线开头。
#4、类和异常的命名，应该每个单词首字母大写。
#5、模块级别的常量，应该采用全大写字母，如果有多个单词就用下划线进行连接。
#6、类的实例方法，应该把第一个参数命名为self以表示对象自身。
#7、类的类方法，应该把第一个参数命名为cls以表示该类自身。
2.3 表达式和语句
在Python之禅（可以使用import this查看）中有这么一句名言：“There should be one-- and preferably only one --obvious way to do it.”，翻译成中文是“做一件事应该有而且最好只有一种确切的做法”，这句话传达的思想在PEP 8中也是无处不在的。
#1、采用内联形式的否定词，而不要把否定词放在整个表达式的前面。例如if a is not b就比if not a is b更容易让人理解。
#2、不要用检查长度的方式来判断字符串、列表等是否为None或者没有元素，应该用if not x这样的写法来检查它。
#3、就算if分支、for循环、except异常捕获等中只有一行代码，也不要将代码和if、for、except等写在一起，分开写才会让代码更清晰。
#4、import语句总是放在文件开头的地方。
#5、引入模块的时候，from math import sqrt比import math更好。
#6、如果有多个import语句，应该将其分为三部分，从上到下分别是Python标准模块、第三方模块和自定义模块总结一下了：
PEP8是一个松散的规范，并不要求所有人强制执行，即使你不按照这个规范，写出来了一个项目，OK，假如这个项目是可以运行的，没有人会说你什么。但，代码不规范不统一，将会在后续的代码维护方面产生问题。比如，下面的简单例子
简单例子1，两数相加，如果按照规范来是这样的：
正确示例：
nm1 = 3
nm2 = 4
print("nm1 + nm2 = " , nm1+nm2)如果想写的跟屎一样难看，那么就这样：
错误示例：
nm1=3
nm2=4
print("nm1+nm2=",nm1+nm2)这里的例子是空格的例子，可以看到，变量定义=后按规范应该有一个空格，print函数也做了适当的空格优化，这样的输出会比较优雅，而不是凑成了一堆。
简单例子2 多模块的引用顺序：
错误示例：
import array
import os
import sys正确示例：
import os
import sys
from numpy import array错误的示例错在哪了呢？虽然array这个类库是可以引用成功，也可以引用到，但，我们不知道这个类库的父类是哪个，后续的代码阅读会给其它不了解情况的人造成困扰，并且，Python内置类库应该在前，第三方在后面，这里没有自定义模块，如果有，那么，自定义模块应该是写到最后的哦。
当然，以上都是一些简单的示例说明PEP8规范，各位同学可以对照以上规范仔细研究并得到一个良好的代码编程习惯。
一个项目如果统一了代码实施标准，那么，对于后面接手的同学来说，这是一个好的开端，否则，将会是一场灾难。
