这一段时间有在解读朋友github / coding上的代码，期间发现自己很多地方不懂，又跑去读了部分Python的库里的源码。读了这么一次，才知道“阅读别人留下的代码”的真正感受。这个是随时更新的，想到什么要加上去的随时加。
1. 全局变量慎用
2. 文件内命名需谨慎...别来个全局变量aaa这样的
3. 括号里的式子比较长的，最好括号前后都留个空格
4. 缩进！不管是什么语言，一定要缩进控制好。如果可以，可以写个脚本将 ‘ ’ 转换成四个空格。感受最深的的就是在我用的Ubuntu上gedit里tab默认为8，每次都要调。有时懒得调或者没留意会觉得挺蛋疼的
5. for student in students 这样写循环的很好懂啊
6. 要对数据进行一个特定处理的函数，最好还是在前一行用注释说明你要干嘛
7、 在一个类里边，如果没什么特殊原因，强烈建议如果用途相同，变量名在不同方法间最好统一
8. 文件名别太随便。文件开头用跨行注释说明这个文件是干嘛的(或能干嘛)，说明的时候最好附上一个综合但简单的例子
9. 像python文档，库文件的话开头有__all__ = [“urlopen”, “URLopener”]列举所有的类 / 方法，并且能对主要(或常用)的类 / 函数的概念进行说明(最好能给个例子，像sgml我开始真看不懂，看了一个start_td就感觉容易了解了
10. 像urllib2.py里挺逗的一个地方就是，告诉你不打算深入学习的用xxx这些函数就好了，其他就别管了
11. 不用死守PEP8(其实我也没认真看过)，但一定要写得易懂。比如( num – tmp1*100 – tmp2*10 )，如果乘号两边还分开就真的容易眼花了。就觉得能用名字说明的别用太多注释。而且命名的话，个人还是喜欢python里用下划线分开各单词这样的，驼峰法倒略反人类，名字一长了看着眼花
12. 用户输入的地方必过滤/转换，输入的数据处理前必先检验长度是否合理
13. 数据处理时觉得可能出错的地方要考虑周全...输入数据的人不一定是正常人...出错的返回给运维的人的信息要明确，让他明白是哪里出错...
14. 关键的地方，别嫌麻烦，try throw catch
15. 要写一个代码超过两百行还不是html的文件时，要规划好代码块，而且要独立一个根据参数输出错误信息用的代码块。这个代码块在测试之初就要写好写完整错误信息的情况
16. 能封装(成文件)的直接封装吧，别把一大堆处理数据的代码直接嵌入到主函数里面
17. 大点的工程，记得交代各文件夹的作用(如果能用命名就足以说明的就最好)
18. 对阅读一大堆代码的人来说，如果能给出目录树状图(请参考Linux上的进程树图)，并且在后面附上它们的相应内容、作用说明，我相信他们会很感激你的
19. 代码重用很重要，包括对文件而言。我读一个50M的文件夹的代码时，发现里面用框架以后，还把要引用的文件到处扔！需要的地方都给扔上一个！我看的时候好崩溃啊好吗
20. 如果你对将来要管理你代码的人的能力没一定的信心的话，请别秀奇葩算法...给条活路别人吧...
21. 团队里的人一起工作的话，要么功能划分和文件管理方面做得很好，不然最好还是要求一下各人编写代码的风格接近一致(或者牛逼的直接一个做了大部分基本工作，顶多给多点钱，但起码其他阅读的人不至于那么崩溃