最近参加了一个比赛，然后看到队友编程的代码，我觉得真的是觉得注释和命名规范的重要性了，因为几乎每个字符都要咨询他，用老师的话来说，这就是命名不规范的后续反应。所以此时的我意识到写一篇关于注释程序的重要性了，因此特地的写一篇文章规范自己，也帮助新手入门。
（这篇文章已经是我自己更新的第三遍了，第一次叫浅谈注释的重要性，那时候我刚入门不久；学着学着我会发现变量名也很重要，第二次是规范变量名；这次我又改了，我觉得不止是这些东西，从长远的来说，编程以后就是自己的工作，或者说工具，所以遵循一套编码规则很重要，这里我继续加如自己的想法）
（又想写在这里，这是第四次了，我又来回味这个编码规范的重要性了，这次是被老师批评后，我又来写了
我们这些初学者，目前要做的就是遵守代码规范，这是最基本的，而且每个团队的规范可能还不一样，以后工作了，尽可能和团队保持一致，目前初学者就按照官方的要求即可
新人进入一个企业，不会接触到核心的架构级别的代码，这些东西大多数有大佬写好了。所以新人要做的就是维护别人的代码，因此代码的可阅读性，良好的可维护性是最重要的，关键的影响性能的代码，不需要我们写，慢慢的写得多了，积累的多了，看几个优秀的代码就会了了，所以，初学者前期关注代码规范，不写bug，就ok）
（这是第五次添加内容了，这次添加的是软件开发目录的规范，为了让自己理解在开发标准软件时候如何布局项目目录结构，以及注意开发规范的重要性）
编程规范的重要性
首先谈一下注释：
注释不止是为了自己以后看的更清楚，还是为了以后的开发人员所准备的，其实一段时间后，当需要对程序做一些修改或者是改正某个bug的时候，可能未来的我们自己都会忘记相关的细节，所以此时注释显得尤为重要。
每条注释以井号（#）开始，一直到该行末尾结束，一直到该行末尾结束。我们可以在注释中放任何东西，因为Python 会完全无视他们的存在。为了写好注释，这里给出以后几条规则：
（1） 假设读者的Python 水平和你一样（比如说，不要去解释 “ 什么是字符串 ” ， 也不要去解释 “ 什么是赋值语句 ”）
（2） 不要去注释那些毫无意义的事情。比如说：
count = count +1 # add one to count
( 3） 很多程序员会在代码上写上一些以 “ TODO ” 或者 “ FIXME ”开始的注释，目的就是为了提醒他们回来编写或清理一些未完成的一些问题。
（4） 如果你在编写某段程序的时候需要使劲思考的话，应该编写注释，以后别人不会在这个地方绞尽脑汁。尤其要注意的是，如果你在开发程序的时候或者函数编写的时候使用要点来描述，尽量写的细致一点，在开发工作完成之后，还应该将原来的要点全部保留下俩直接做解释。
（5） 同样，如果某个bug很难查明，或者其修改方案比较复杂，那么你就应该编写一条注释对其进行解释。如果不这么做，那么今后其他复杂该部分的代码的程序员就会可能认定他们没有必要这么复杂并将其改为原来的样子，从而将你的心血付诸东流。
（6）如果需要大量的注释才能解释清楚某段代码的作用，那么就应该对这些代码进行整理，比如，如果需要分别对一个函数的15个列表进行解释，那么就应该将该函数拆分成更小的代码块，每隔分别只处理较小的几个列表。
（7） 过时的注释还不如没有注释，因此修改某段代码后，一定要检查相关注释，并对其做出适当的修改以保证其仍然能够准确描述代码的功能。
（8） 注释不是越多越好，弄得整篇代码都是注释，却很少看到代码，这样就曲解了注释的意思了。
所以说，一定要养成良好的注释代码的习惯，边写代码边注释，及时的记录下来你的思路，举个例子，代码是鱼，注释就是水，有了正确的注释，鱼才能更好的生存。还有就是多提高自己对代码的解释能力，用精炼的语言表达出代码的核心价值所在，那么你写的代码就是成功的。
下面举个例子
def find_two_smallest(L):
'''Return a tuple of the indices of the two smallest values in list L'''
smallest = min(L)
min1 = L.index(smallest)
L.remove(smallest)
next_smallest = min(L)
min2 = L.index(next_smallest)
L.insert(min1,smallest) #为了获取第二个最小值在原始列表中的索引，我们还需要根据实际情况给min2加1
if min1<=min2:
min2+=1
return(min1,min2)
Python 中的特殊注释（大家注意一下）
比如：Python有一行声明python编码格式的单行注释。这行注释指定文件为 utf-8 编码。这行特殊注释只能放在文件的第一行或者开头
#_*_coding:utf-8_*_
还有一种是说明脚本语言是python的，是要用/usr/bin下面的程序（工具）python，这个解释器，来解释python脚本，来运行python脚本的。
#!/usr/bin/python
再说一下规范命名变量：
因为名字不能乱起，要是你一个想法，他一个想法，大家都对对方的名称不了解，这样也很难持续下去，因此这里说一下变量规范命名的规则和注意事项。
1，变量定义规则：
1，变量名只能是字母，数字或者下划线的任意组合
2，变量名的第一个字符不能是数字
3，关键字不能生成变量名
2，变量规范命名注意事项：
1，变量名不能过长
2，变量名词不达意思
3，变量名为中文，拼音
3，总体命名规则：
1 ，尽量单独使用小写字母‘l’，大写字母‘O’等容易混淆的字母。
2 ，模块命名尽量短小，使用全部小写的方式，可以使用下划线。
3 ，包命名尽量短小，使用全部小写的方式，不可以使用下划线。
4 ，类的命名使用CapWords的方式，模块内部使用的类采用_CapWords的方式。
5 ，异常命名使用CapWords+Error后缀的方式。
6 ，全局变量尽量只在模块内有效，类似C语言中的static。实现方法有两种，一是__all__机制;二是前缀一个下划线。
7 ，函数命名使用全部小写的方式，可以使用下划线。
8 ，常量命名使用全部大写的方式，可以使用下划线。
9 ，类的属性（方法和变量）命名使用全部小写的方式，可以使用下划线。
10，类的属性有3种作用域public、non-public和subclass API，可以理解成C++中的public、private、protected，non-public属性前，前缀一条下划线。
11 ，类的属性若与关键字名字冲突，后缀一下划线，尽量不要使用缩略等其他方式。
12 ，为避免与子类属性命名冲突，在类的一些属性前，前缀两条下划线。比如：类Foo中声明__a,访问时，只能通过Foo._Foo__a，避免歧义。如果子类也叫Foo，那就无能为力了。
13 ，类的方法第一个参数必须是self，而静态方法第一个参数必须是cls。
下面说一下排版问题：
一，代码排版：
1 ，缩进。4个空格的缩进（编辑器都可以完成此功能），不使用Tap，更不能混合使用Tap和空格。
2 ，每行最大长度79，换行可以使用反斜杠，最好使用圆括号。换行点要在操作符的后边敲回车。
3 ，类和top-level函数定义之间空两行；类中的方法定义之间空一行；函数内逻辑无关段落之间空一行；其他地方尽量不要再空行。
二，文档排版：
1 ，模块内容的顺序：模块说明和docstring—import—globals&constants—其他定义。其中import部分，又按标准、三方和自己编写顺序依次排放，之间空一行。
2 ，不要在一句import中多个库，比如import os, sys不推荐。
3 ，如果采用from XX import XX引用库，可以省略‘module.’，都是可能出现命名冲突，这时就要采用import XX。
三，空格的使用：
总体原则，避免不必要的空格
1 ，各种右括号前不要加空格。
2 ，逗号、冒号、分号前不要加空格。
3 ，函数的左括号前不要加空格。如Func(1)。
4 ，序列的左括号前不要加空格。如list[2]。
5 ，操作符左右各加一个空格，不要为了对齐增加空格。
6 ，函数默认参数使用的赋值符左右省略空格。
7 ，不要将多句语句写在同一行，尽管使用‘；’允许。
8 ，if/for/while语句中，即使执行语句只有一句，也必须另起一行。
最后谈一下对自己和大家的建议
1 ，编码中考虑到其他python实现的效率等问题，比如运算符‘+’在CPython（Python）中效率很高，都是Jython中却非常低，所以应该采用.join()的方式。
2 ，尽可能使用‘is’‘is not’取代‘==’，比如if x is not None 要优于if x。
3 ，使用基于类的异常，每个模块或包都有自己的异常类，此异常类继承自Exception。
4 ，异常中不要使用裸露的except，except后跟具体的exceptions。
5 ，异常中try的代码尽可能少。比如：
try:
value = collection[key]
except KeyError:
return key_not_found(key)
else:
return handle_value(value) 要优于 try:
# Too broad!
return handle_value(collection[key])
except KeyError:
# Will also catch KeyError raised by handle_value()
return key_not_found(key)
6 ，使用startswith() and endswith()代替切片进行序列前缀或后缀的检查。比如：
Yes: if foo.startswith('bar'):
优于
No: if foo[:3] == 'bar':
7 ，使用isinstance()比较对象的类型。比如
Yes: if isinstance(obj, int): 优于 No: if type(obj) is type(1):
8 ，判断序列空或不空，有如下规则
Yes: if not seq:
if seq: 优于 No: if len(seq)
if not len(seq)
9 ，字符串不要以空格收尾。
10 ，二进制数据判断使用 if boolvalue的方式。
软件开发目录规范的重要性
为什么要设计好目录结构?
"设计项目目录结构"，就和"代码编码风格"一样，属于个人风格问题。对于这种风格上的规范，一直都存在两种态度:
- 一类同学认为，这种个人风格问题"无关紧要"。理由是能让程序work就好，风格问题根本不是问题。
- 另一类同学认为，规范化能更好的控制程序结构，让程序具有更高的可读性。
我是比较偏向于后者的，因为我是前一类同学思想行为下的直接受害者。我曾经维护过一个非常不好读的项目，其实现的逻辑并不复杂，但是却耗费了我非常长的时间去理解它想表达的意思。从此我个人对于提高项目可读性、可维护性的要求就很高了。"项目目录结构"其实也是属于"可读性和可维护性"的范畴，我们设计一个层次清晰的目录结构，就是为了达到以下两点:
- 可读性高: 不熟悉这个项目的代码的人，一眼就能看懂目录结构，知道程序启动脚本是哪个，测试目录在哪儿，配置文件在哪儿等等。从而非常快速的了解这个项目。
- 可维护性高: 定义好组织规则后，维护者就能很明确地知道，新增的哪个文件和代码应该放在什么目录之下。这个好处是，随着时间的推移，代码/配置的规模增加，项目结构不会混乱，仍然能够组织良好。
所以，我认为，保持一个层次清晰的目录结构是有必要的。更何况组织一个良好的工程目录，其实是一件很简单的事儿。
目录组织方式
关于如何组织一个较好的Python工程目录结构，已经有一些得到了共识的目录结构。在*的这个问题上，能看到大家对Python目录结构的讨论。
这里面说的已经很好了，我也不打算重新造*列举各种不同的方式，这里面我说一下我的理解和体会。
假设你的项目名为foo, 我比较建议的最方便快捷目录结构这样就足够了:
Foo/
|-- bin/
| |-- foo
|
|-- foo/
| |-- tests/
| | |-- __init__.py
| | |-- test_main.py
| |
| |-- __init__.py
| |-- main.py
|
|-- docs/
| |-- conf.py
| |-- abc.rst
|
|-- setup.py
|-- requirements.txt
|-- README
简要解释一下:
- bin/: 存放项目的一些可执行文件，当然你可以起名script/之类的也行。
- foo/: 存放项目的所有源代码。(1) 源代码中的所有模块、包都应该放在此目录。不要置于顶层目录。(2) 其子目录tests/存放单元测试代码； (3) 程序的入口最好命名为main.py。
- docs/: 存放一些文档。
- setup.py: 安装、部署、打包的脚本。
- requirements.txt: 存放软件依赖的外部Python包列表。
- README: 项目说明文件。
除此之外，有一些方案给出了更加多的内容。比如LICENSE.txt,ChangeLog.txt文件等，我没有列在这里，因为这些东西主要是项目开源的时候需要用到。如果你想写一个开源软件，目录该如何组织，可以参考这篇文章。
下面，再简单讲一下我对这些目录的理解和个人要求吧。
关于README的内容
如何写标准的README文件，请看博客：http://www.cnblogs.com/wj-1314/p/8547763.html
这个我觉得是每个项目都应该有的一个文件，目的是能简要描述该项目的信息，让读者快速了解这个项目。
它需要说明以下几个事项:
- 软件定位，软件的基本功能。
- 运行代码的方法: 安装环境、启动命令等。
- 简要的使用说明。
- 代码目录结构说明，更详细点可以说明软件的基本原理。
- 常见问题说明。
关于requirements.txt和setup.py
setup.py
一般来说，用setup.py来管理代码的打包、安装、部署问题。业界标准的写法是用Python流行的打包工具setuptools来管理这些事情。这种方式普遍应用于开源项目中。不过这里的核心思想不是用标准化的工具来解决这些问题，而是说，一个项目一定要有一个安装部署工具，能快速便捷的在一台新机器上将环境装好、代码部署好和将程序运行起来。
这个我是踩过坑的。
我刚开始接触Python写项目的时候，安装环境、部署代码、运行程序这个过程全是手动完成，遇到过以下问题:
- 安装环境时经常忘了最近又添加了一个新的Python包，结果一到线上运行，程序就出错了。
- Python包的版本依赖问题，有时候我们程序中使用的是一个版本的Python包，但是官方的已经是最新的包了，通过手动安装就可能装错了。
- 如果依赖的包很多的话，一个一个安装这些依赖是很费时的事情。
- 新同学开始写项目的时候，将程序跑起来非常麻烦，因为可能经常忘了要怎么安装各种依赖。
setup.py可以将这些事情自动化起来，提高效率、减少出错的概率。"复杂的东西自动化，能自动化的东西一定要自动化。"是一个非常好的习惯。
setuptools的文档比较庞大，刚接触的话，可能不太好找到切入点。学习技术的方式就是看他人是怎么用的，可以参考一下Python的一个Web框架，flask是如何写的: setup.py
当然，简单点自己写个安装脚本（deploy.sh）替代setup.py也未尝不可。
requirements.txt
这个文件存在的目的是:
- 方便开发者维护软件的包依赖。将开发过程中新增的包添加进这个列表中，避免在
setup.py安装依赖时漏掉软件包。 - 方便读者明确项目使用了哪些Python包。
这个文件的格式是每一行包含一个包依赖的说明，通常是flask>=0.10这种格式，要求是这个格式能被pip识别，这样就可以简单的通过 pip install -r requirements.txt来把所有Python包依赖都装好了。具体格式说明： 点这里。
关于配置文件的使用方法
注意，在上面的目录结构中，没有将conf.py放在源码目录下，而是放在docs/目录下。
很多项目对配置文件的使用做法是:
- 配置文件写在一个或多个python文件中，比如此处的conf.py。
- 项目中哪个模块用到这个配置文件就直接通过
import conf这种形式来在代码中使用配置。
这种做法我不太赞同:
- 这让单元测试变得困难（因为模块内部依赖了外部配置）
- 另一方面配置文件作为用户控制程序的接口，应当可以由用户*指定该文件的路径。
- 程序组件可复用性太差，因为这种贯穿所有模块的代码硬编码方式，使得大部分模块都依赖
conf.py这个文件。
所以，我认为配置的使用，更好的方式是，
- 模块的配置都是可以灵活配置的，不受外部配置文件的影响。
- 程序的配置也是可以灵活控制的。
能够佐证这个思想的是，用过nginx和mysql的同学都知道，nginx、mysql这些程序都可以*的指定用户配置。
所以，不应当在代码中直接import conf来使用配置文件。上面目录结构中的conf.py，是给出的一个配置样例，不是在写死在程序中直接引用的配置文件。可以通过给main.py启动参数指定配置路径的方式来让程序读取配置内容。当然，这里的conf.py你可以换个类似的名字，比如settings.py。或者你也可以使用其他格式的内容来编写配置文件，比如settings.yaml之类的。