一、本学期编码规范
1.不要使用难懂的技巧性很高的语句，除非很有必要。高技巧语句不等于高效率的程序，实际上程序的效率关键在于算法。
2.去掉没必要的公共变量。公共变量是增大模块间耦合的原因之一。全局变量虽然好用，但是宜少不宜多这样能保证数据的安全性。
3.当向公共变量传递数据时，最好做数据合法性检查。有必要最好做一下，因为万一出了问题是不好检测出来的。
4.构造仅有一个模块或函数可以修改、创建，而其余有关模块或函数只访问的公共变量，防止多个不同模块或函数都可以修改、创建同一公共变量的现象。还是前面讲到的数据安全性问题，可以通过静态函数实现，且整个系统都要保持一致。
5.仔细设计结构中元素的布局与排列顺序， 使结构容易理解、 节省占用空间， 并减少引起误用现象。
6.尽量减少没有必要的数据类型默认转换与强制转换。
7.对所调用函数的错误返回码要仔细、全面地处理。Linux系统里是不允许有空函数的。
8.防止将函数的参数作为工作变量。将函数的参数作为工作变量， 有可能错误地改变参数内容， 所以很危险。 对必须改变的参数，最好先用局部变量代之，最后再将该局部变量的内容赋给该参数。
9.一个函数仅完成一件功能。
10.避免设计多参数函数，不使用的参数从接口中去掉。目的减少函数间接口的复杂度，参数多的话可以通过结构体实现。
11.非调度函数应减少或防止控制参数，尽量只使用数据参数。避免函数功能不明确，给调试带来麻烦。
12.检查函数所有参数输入的有效性。功能不明确较小的函数，特别是仅有一个上级函数调用它时， 应考虑把它合并到上级函数中， 而不必单独存在。
13.设计高扇入、合理扇出（小于7） 的函数。函数较合理的扇出（调度函数除外） 通常是 3-5.较良好的软件结构通常是顶层函数的扇出较高， 中层函数的扇出较少， 而底层函数则扇入到公共模块中。还是强调函数的高复用性和可读性。
14.避免使用BOOL参数。TURE/FALSE 的含义是非常模糊的，这点确实有点惊讶，对于那些内存要求不是很苛刻的能不用就不用吧。
15.对于提供了返回值的函数， 在引用时最好使用其返回值。
16.当一个变量名较长且有较多引用时（一般是结构的成员）， 可以用一个意义相当的宏代替。也可以定义一个局部变量，在用之前对局部变量赋值。
17.在同一项目组或产品组内， 调测打印出的信息串的格式要有统一的形式。 信息串中至少要有所在模块名（或源文件名） 及行号。行号和文件名可以用宏__LINE__和__FILE__实现。
18.使用断言来发现软件问题， 提高代码可测性。断言可以对在系统中隐藏很深， 用其它手段极难发现的问题进行定位。
19.在编写代码之前， 应预先设计好程序调试与测试的方法和手段， 并设计好各种调测开关及相应测试代码如打印函数等。
20.在保证软件系统的正确性、 稳定性、可读性及可测性的前提下， 提高代码效率。
21.避免循环体内含判断语句， 应将循环语句置于判断语句的代码块之中。笔者确实踩过这样的坑，并且真的很难发现是什么问题。另外循环嵌套尽量不要超过三层且不要太复杂。
22.尽量用乘法或其它方法代替除法，特别是浮点运算中的除法。浮点运算除法要占用较多 CPU 资源。应为一般的cpu只有硬件乘法器。
23.过程/函数中申请的（为打开文件而使用的）文件句柄，在过程/函数退出之前要关闭。分配的内存不释放以及文件句柄不关闭， 是较常见的错误， 而且稍不注意就有可能发生。
这类错误往往会引起很严重后果，且难以定位
24.有可能的话， if语句尽量加上else分支， 对没有else分支的语句要小心对待； switch语句必须有default分支。
25.时刻注意表达式是否会上溢、 下溢。
26.打开编译器的所有警告开关对程序进行编译。
27.某些语句经编译后产生警告，但如果你认为它是正确的，那么应通过某种手段去掉告警信息。
28.使用代码检查工具（如C语言用PC-Lint）对源程序检查。使用软件工具（如 LogiSCOPE）进行代码审查。用过其中一个，效果不理想可能是不会用吧。
29.不应通过“试” 来解决问题，应寻找问题的根本原因。最精辟的原则之一，可很多人就是通过“试”。
30.对自动消失的错误进行分析，搞清楚错误是如何消失的。最精辟的原则之一，对于提高能力有很大帮助。
二、读《数学之美》的体会
本书介绍了Google产品中涉及的自然语言处理、统计语言模型、中文分词、信息度量、拼音输入法、搜索引擎、网页排名、密码学等内容背后的数学原理。让我们看到了布尔代数、离散数学、统计学、矩阵计算、马尔科夫链等似曾相识的内容在实际生活中的应用。相比于其他数学题材书籍，吴军老师把抽象、深奥的数学方法解释得通俗易懂，书中同时引用了诸多的历史典故和人物介绍，给人以很多启发，也让人由衷感叹数学的简洁和强大。虽是数据专业毕业，但是才疏学浅，无力对数学的美进行阐述。仅就书中两个比较喜欢的地方发表一点不成熟的见解，与诸位共勉。
其一，在讲Google的搜素引擎反作弊时谈到做事情的两种境界'道”和“术”，术就是具体的做事方法，而道则是隐藏在问题背后的动机和本质。在术这个层面解决问题要付出更多的努力，有点类似于我们常说的“头疼医头，脚疼医脚”，暂时不疼了，过几天复发了，再去医治，如此往复，无法从根本上解决;而只有找到了致病原因，才能做到药到病除，根本治愈。本人之前参与过行内月终自动核对的研发，月终核对初期数据的不一致性只能靠数百业务人员人工核对数据差异，然后修改数据，每月1日都要加班加点，工作量很大，这是从术上解决问题。后来找到了产生差异的原因是会计核算时的利息调整造成的，把这些数据接过来进行相应冲减后差异就消失了，业务人员也不用来加班了，这才是从道上解决问题。
其二，是在做中文网页排名时提到的从业界成功的秘诀之一:“先帮助用户解决80%的问题，再慢慢解决剩下的20%的问题。许多时候做事失败，不是因为人不够优秀，而是做事的方法不对。一开始追求大而全的解决方案，之后长时间不能完成，最后不了了之”。我们在做项目时也是一样，业务有时要的功能非常急，可能有些功能也实现不了(比如系统响应时间长、查询明细不能支持省行等)。这时我们就要将焦点关注在那些可以实现的80%的功能上，哪怕刚刚上线的系统界面丑点，操作复杂点，反应速度慢点，但是至少业务有可用的系统，剩下时间再去优化那剩下的20%。这样可以帮助我行抢占先机，在与同行业的竞争中取得主动。如果等待我们把所有的细节都搞清楚再动手开发，力求完美，那么很可能系统能够上线的时候业务已经不需要了。
数学之美，也就是简单之美。希望大家能够喜欢数学，喜欢数学之美。
