刚开始学的时候就要注意编码规范了，所以整理了一下，以便养成一个编码好习惯。不然以后真的不好改。
代码被读的次数远大于被写的次数。
作为一名程序员（使用任何语言），你能做出最重要的事情之一就是写出易于阅读的代码。
原则
在开始讨论Python社区所采用的具体标准或是由其他人推荐的建议之前，考虑一些总体原则非常重要。
请记住，可读性标准的目标是提升可读性。这些规则存在的目的就是为了帮助人读写代码。
1、假定你的代码需要维护
你很容易相信在某时自己所完成的工作在未来不需要添加内容或对其进行维护。在编写代码时，你很难预料到未来的需求，并且会低估自己引入Bug的倾向。然而，所编写的代码很少不需要修改一直存在的。
如果你假设自己的编写的代码会‘一劳永逸’，之后无需再阅读、调试或修补，那么就会非常容易陷入忽视其他可读性原则的境地。这仅仅是因为你相信‘这次你编写的代码不会需要修改，所以不用花费时间编写可读性高的代码’。
因此，对自己所写代码不需维护的直觉不相信才是上策。稳赚不赔的办法是赌自己将会再次看到自己编写的代码。即使你不维护，别人也会维护。
2、保持一致性
一致性的两个方面分别为：内部一致性和外部一致性。
无论是从代码风格和代码结构层面来讲，代码都要尽可能的保持内部一致性。无论是哪种格式化规则，代码风格都要贯穿项目保持一致性。代码结构的一致性也就是将同样类型的代码放到一起，这样项目容易把控。
代码还应该保持外部一致性。项目与代码的结构应与其他人保持一致，如果一个新的开发人员打开你的项目，你不应该让他的反应是：“我从来没看过像这样的东西”。社区指导原则很重要，因为这些原则是开发人员加入到你的项目所期望的原则。类似的，请认真看待在使用特定框架时完成任务以及组织代码时所采用的标准。
3、考虑对象在程序中存在的方式，尤其是那些带有数据的对象
存在论（Ontology）的主要意思是“关于存在的研究”。在哲学的上（在该领域这个词很常用），存在论是关于现实与存在本质的研究，是形而上学的子集。
而对于写软件程序来说，存在论指的是关注不同的“事物”在应用程序中的存在方式。如何在数据库中表示概念？或是用类结构来表示？
这类问题最终影响你编写或组织代码的方式。是否使用继承或组合来组织两个类之间的关系？使用数据库的哪个表来完成这项功能或是这个列属于那个表？
这些建议最终归结为“在编写代码之前先思考‘’，尤其是思考程序希望实现的目标，以及应用程序之间如何交互，应用程序是一个对象与数据交互的世界。那么，它们之间的协作需要遵循的规则是什么？
4、不要做重复工作
在编写代码时，请考虑随着时间的推移重复使用的值将会变更的情况。该值是否被用于多个模块或函数中？如果有必要修改，需要花费多大的代价？
同样的原则用于函数。在应用程序中你是否拥有大量的重复代码？如果这些重复代码行数较多，可以先将其抽象到一个函数中去，如果出现修改的必要，则更容易管理。
另一方面，对于这个原则不要过犹不及。并不是所有的值都需要在某块中定义常量（这样有损可读性和维护性）。请明智判断，不断问自己这样的问题：“如果需要变更该代码，在所有位置进行变更所需要的成本是多少？”。
5、让注释讲故事
代码时一个故事。在用户与程序的交互中，从开始到结束，代码时所发生故事的说明。程序从某一点开始（可能带有一点输入），沿着一系列“选择自己的冒险故事”步骤到达终点，并结束（很可能带一些输出结果）
采用的注释风格可以是在每某一些行代码之前就添加一段注释，用于解释代码的功能。如果代码时一个故事，那么注释就是故事的解释与旁白。
如果叙事型注释做的好，读者就可以通过阅读注释了解故事，从而解析代码（例如，当尝试解决问题或维护代码时），然后就可以从零开始快速了解所需维护的代码，这样就可以专注于代码本身所表示的意义。
叙事型注释还可以帮助解释代码的意图。它可以回答这样的问题：“这段代码的编写者需要完成的目的是什么？”，偶尔，还可以帮助回答问题：“为什么以这种方式完成工作”？这些问题是你阅读代码时很自然就会问的问题为这些问题提供答案有助于了解这些内容。
因此，注释用于解释代码中不显而易见或复杂部分的原理。如果使用了有点复杂的算法，请考虑将指向解释模型文章的链接以及其他使用实例加入注释。
6、奥卡姆剃刀原则
通俗来讲，编写可读性代码最重要的原则就是奥卡姆剃刀原则：最简单的解决方案通常是最好的。在他的“Python之禅”的博文页面中（http://www.python.org/dev/peps/pep-0020/），集合了一些编程格言（例如在Python的控制台中输入"import this"就可以看到这篇博文），Tim peters 也包括类似下面格言：“如果你无法想别人描述你的方案，那肯定不是一个好方案”。
上述原则在代码如何运行与代码外观的层次上都生效。当提到代码运行时，简单的系统更加容易维护，实现的简单化意味着更少引入复杂的Bug，那些维护你代码的人（包括你自己），更容易凭直觉来理解代码所表示的含义，并在不采坑的情况下为程序增加代码。
至于代码的外观，请记住，尽可能是的阅读代码就好像是在了解代码所做的工作，而不是为了解析词汇。词汇是手段，而故事才是最终目的。写一条‘不要使用三元运算符‘’很容易，然而仅遵守这些规则（虽然有价值）并不是代码明细的充分条件。应该重点关注以尽可能简洁的方式编写和组织代码。
标准
Python社区大部分遵守所谓的 PEP 8（http://www.python.org/dev/peps/pep-0008）指导原则，PEP 8由Guido van Rossum(Python之父)编写并被大多数主流Python项目所采用，其中包括Python的标准库。
PEP 8的普遍性是其强大的原因之一。该标准被大多数社区项目所采用，因此你可以预计你遇到的大多数Python代码都遵守该标准。当以这种方式编写代码时，代码会更容易阅读，也更容易编写。
1、简洁的规则
- PEP 8的大多数指导原则都很简单明了，部分重点如下
- 使用4个空格缩进，而不是制表符（Tab键）
- 变量应该使用下划线连接，而不是驼峰式命名规则（使用my_var 而不是myVal）。类名称以字母开头就是驼峰式命名风格（例如：MyClass）
- 如果一个变量的用处是：“仅内部使用”，那么在变量名称之前加上下划线。
- 在运算符前后加上单空格（例如，x + y，不是x+y），也包括赋值运算符（z = 3,不是z=3）。只有在关键字参数的情况下该规则不适用，在这种情况下，空格可以省略。
- 在列表和字典省略不必要的空白（例如：[1,2,3,4]而不是[ 1,2,3,4 ]）。
2、文档字符串
请记住在Python中，如果在一个函数或类中的第一个语句是字符串，该字符串会自动赋值给一个特殊的__doc__变量，该变量在条用Help（和一些其他的类），时会使用。
PEP 8规定文档字符串的是必须的
‘’‘Do X , Y, and Z, then return the result. ’‘’
如果文档字符串是一行，那么需要在类或函数体之前加空行。如果文档是多行，则将结束的双引号单独的放一行。
3、空行
空行用于逻辑分块。
PEP 8规定“最高级”的类和函数定义之间有两个空行。
class A(object): pass class B(object): pass
除了最高级之外，PEP 8还规定类和函数的定义以一个空行分隔。
class A(object): def foo(self): pass def bar(self): pass
在函数或其他的代码块中使用单空行分隔逻辑段是合理的。请考虑在逻辑段之前使用注释解释代码块的作用。
4、导入
Python允许绝对路径导入和相对路径导入。在Python2中，解释器会尝试相对导入，如果找不到路径，然后在尝试绝对导入。
在Python3中，使用特殊语法来标记相对导入——以（.）开头——‘正常’的导入方式只会尝试相对路径。Python3的语法在Python2.6以后的版本可以使用，另外，可以使用from_future_import absolute_import关闭隐式的相对导入。
如果可能，尽量使用绝对路径导入。如果必须使用相对路径，请使用显示的导入风格。如果你是Python2.6、Python2.7编码，请考虑选择Python3的显示风格。
当导入模块时，每个模块应该单独占一行。
import os import sys
然而如果从一个模块导入多个名称，可以将这些名称分组到一行中。
from datetime import data, datetime, timedelta
此外，虽然PEP 8并没有强制要求，但可以考虑以包的形式将导入分组。对于每一组，按照字母表顺序排序。
另外，在导入时，请不要忘了使用as关键字给导入的内容起别名。
from foo.bar import really_long_name as name
这使得你可以简化被频繁使用的长名或不规范命名的名称。
5、变量
如前所述，变量名称使用下划线连接，而不要使用驼峰式代码风格，此外，起一个具有描述性的名称同样重要。
通常情况下，使用非常短的变量名称并不合适，虽然某些情况下这样做也能接受。如：(for k , v in a）。
应避免函数的命名与Python语言中常用名称重复，就算是解释器允许也不能用。无论在任何情况下，都不要命名某个对象为sum或print。类似的，应避免用list或dict之类的名称。
如果必须要命名一个与Python关键字同名的的变量，惯例是在变量名之后加下划线；相比修改名称的编写来说，这样更加可行。例如你想使用class，应该是class_。
6、注释
注释的编写应该使用英语的完整语句，注释块应该放在相关代码之前。首字母大写，拼写正确。
同时要保证注释更新。如果代码变更，注释也要变。
模块可能包含一个注释头，通常有版本控制系统生成，其中包括文件版本的信息。这使得查看文件是否被修改变得 容易，尤其是将模块分发给别人使用时。
7、行长度
PEP8 要求行长度不超过79个字符，文档字符串不超过72个字符。
当行过长时，使用圆括号封装是最佳方式，也可以使用‘’字符。