代码规范的必要性
关于代码规范，存在有以下几种偏见甚至错误的观点
- 观点一 这些规范都是官僚制度下产生的浪费大家的编程时间、影响人们开发效率, 浪费时间的东西。
- 观点二 我是个艺术家，手艺人，我有自己的规范和原则。
- 观点三 规范不能强求一律，应该允许很多例外。
- 观点四 我擅长制定编码规范，你们听我的就好了。
对于观点一， MarkCC讲述了他在Google的亲身经历，他曾经看过Google的codebase，令其惊讶的是他居然能够读懂这些代码，而原因很简单，就是Google的开发人员都遵循着相同的代码规范，这些代码规范能够帮助程序员们看懂任何一段遵守规范写出来的代码。也许有人会讲，遵守这些规范会影响开发效率，但事实上开发人员是经常变动的，而且代码通常是需要维护的，试想一下，代码的维护人员在阅读代码时，大部分的时间只是为了理清基本的语法结构，那么开发时候遵循相同代码规范所耗费的时间就显得那么微不足道了，而且代码规范只要熟悉并加以遵循，那么对于编码几乎不产生任何开发效率上的负担。正是因为有一个统一的标准，当你在读一段代码时，无论它是否是你写的，只要限定同样的代码结构，同样的命名约定，你会发现根本就无需多么费力的去读代码，因为你能轻易识别出代码结构。因而我们更加愿意选择在开发时遵循相同的代码规范。
对于观点二，有时程序员会对自己的代码风格很满意，认为从自己的代码中可以体现个性以及自己的思维过程，更是自己技能和创造力的体现，倘若被迫去遵守那些蹩脚的标准，那么无疑是对自己创造力的扼杀。然而事实上个人的思想和创造力不应体现在琐碎的语法细节上，而应当蕴含在程序的内部。相同的代码规范事实上更容易让别人看到你的创造力，因为别人能够理解你在做什么，而无需考虑琐碎的语法细节。
对于观点三，也许有人会认为代码规范不是专门针对特定项目设计的，因而很大程度来讲这个代码规范对于某个特定的项目来讲不是最优的。然而，代码规范是对语法的规定，并不最优不意味着不好，语法规范可能降低具体项目的效益，但同时也增加了大规模项目组织的效益。MarkCC介绍了他的经验，他认为一个项目具有特定的代码规范这件事没有错，最好的做法是在一个大规模的代码规范框架下，针对具体的项目进行扩展，使其拥有项目特定的语法风格和结构。
对于观点四，每个程序员都对编码风格有强烈的自我认同。这种感觉深植于每个人的自负中，每当和同事遇到是否应该在关键词周围使用空格时，这种讨论很容易升级而僵持不下。但是，静下来想想——这真的无所谓。不管是不是在关键词周围使用了空格，只要能达成一致，大家都能从中获得易维护和集体所有制的好处。在这种情况中，闭着眼睛，遵循一种编码风格就行了。
代码复审（结对队友：金哉仁）
代码复审的评判标准参考博客：Stop More Bugs with our Code Review Checklist
复审从代码概况，代码安全性，代码文档，代码的测试四个方面展开。
具体审核点列举如下：
1.综述：
- 代码的有效性检查
- 代码模块化检查
- 代码的可读性审查
- 代码风格检查
- 代码冗余性检查
- 代码规范性检查
- 代码的可维护性检查
- 代码的可扩展性检查
2.安全性：
- 输入的安全性检查
- 输出的安全性检查
- 函数参数传递的安全性检查
3.代码文档：
- 关键代码的意图注释
- 函数注释
- 非正常情况，边界情况注释
- 第三方库函数调用注释
- 数据结构注释
- 不完整代码注释
4.测试：
- 代码的可测试性
- 测试的全面性
- 测试的有效性
- 测试的可替代性（用已有API代替测试代码）
代码复审的结果采用思维导图的方式给予更加直观的展示，如下图：
