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