1. 是否需要有代码规范
对于是否需要有代码规范，请考虑下列论点并反驳/支持：
- 这些规范都是官僚制度下产生的浪费大家的编程时间、影响人们开发效率, 浪费时间的东西。
- 我是个艺术家，手艺人，我有自己的规范和原则。
- 规范不能强求一律，应该允许很多例外。
- 我擅长制定编码规范，你们听我的就好了。
我不赞同以上任何一个观点。
相信大家在阅读别人的代码的时候，先不提每个人思维上的区别，总有那么些时候觉得看起来别扭，我想更多的就是由于代码规范不统一所造成的，就好像一句话，每个人的语言习惯不一样，说出来的感觉也不一样，即使都能互相听懂，但是还是会觉得有些不适应一样。
那么为什么在有代码规范的情况下仍然有这样的问题呢，主要是，人都不是那么愿意去改变自己的，程序员也是人。同时，管理者对制定的规范没有彻底执行和检查，一方面也不能完全怪管理者，毕竟代码那么多，也不能检查的多彻底，还是要从每个程序员自身开始有意识的约束才行。
有些人会认为：遵守编码规范不能给项目带来利益，也不能让客户看到我们为此付出的努力，其完全是团队自发的行为，没有必要做硬性的要求。还有些人有更好的理由：编码规范会破坏创造性和程序质量。我认为，编码规范，在软件构件以及项目管理中，甚至是个人成长方面，都发挥着重要的作用，好的编码规范是提高我们代码质量的最有效的工具之一。
编码规范的作用：
1.提高可读性
2.统一全局，促进团队协作
3.有助于知识传递，加快工作交接
4.减少名字增生，降低维护成本
5.强调变量之间的关系，降低缺陷引入的机会
6.提高程序员的个人能力
代码规范并不是一个绝对的约束，而应该是一种习惯，一个大家都自觉去遵守的习惯，我想这就像不应该随地扔垃圾一样，道理都懂，然而仍然也有很多人不能去遵守，而同样，两者都在向成为习惯的路上发展着。代码规范在团队合作上有着巨大的作用，可以让团队成员间能更快地理解彼此的代码，从而能让团队更专注于应该解决问题，不仅缓解了工作的压力也提高了工作的效率。
****************代码复查*******************
- 变量和常量的命名是否与约定保持一致?是
- 是否存在容易混淆的相似的变量和属性名?是
- 变量和属性是否书写正确?是
- 非局部变量是否能用局部变量替换?否
- 变量和属性是否被正确的初始化?不适用
- 所有的for循环的控制变量是否都在循环顶部被声明?是
- 是否有应该命名为常量的文字常量?否
- 变量和属性是否可以用常量替换?否
- 属性是否可以用本地变量?否
- 所有的属性是否都有正确的访问限制符?否
- 方法名的描述方法是否与命名约定一致?是
- 每个方法的参数值在使用之前是否都作了检查?否
- 对于每一个方法,它是否都返回了正确的值?是
- 每一个类是否都有正确的构造函数和析构函数?否
- 在子类中是否有应该放到父类中的通用成员?否
- 类的继承层次是否能被简化?否
- 对于每一个数组引用,下标值是否在定义的范围内?是
- 对于对象和数组引用,是否确定其值应为非空?否
- 是否存在不同类型数据之间的混合计算?是
- 在计算中是否存在上溢或下溢的可能?是
- 关于数值计算的顺序和优先级的假设是否正确?是
- 是否用了括号来避免模糊不清?否
- 对每一个布尔测试,正确条件是否被检查?否
- 比较操作符是否正确?是
- 每个布尔表达式是否都正确?是
- 比较操作是否存在不引人注意的副作用?否
- 对于每一个循环:是否选用了最佳的循环结构?否
- 所有的循环是否都能结束?是
- 如果一个循环有多个出口,是否每个出口都有必要并且得到正确处?否
- switch声明是否都有default条件?是
- 是否所有的case-switch-break对应关系都已更正并加上批注？否
- 循环和分支的嵌套是否过深?是否正确?是
- 是否有if嵌套可以转换程switch嵌套?是
- 空控制叙述是否都正确，并加上括号及批注？否
- 所有的异常是否都得到了正确的处理?否
- 每一个方法是否都结束?是
- 文件在被使用之前是否都被打开?是
- 输入对象的属性是否与使用的文件一致?是
- 文件在被使用之后是否都被关闭?是
- 文本中是否有拼写和语法上的错误?否
- 所有的I/O异常处理的是否合理?否
- 方法调用的参数的数量,顺序,类型和值是否与该方法声明一致?是
- 如果对象或数组被传递,它们是否改变?是否被调用方法正确改变?是
- 每一个方法,类和文件是否都有适当的头注释?否
- 每一个属性,变量和常量的声明是否都有注释？否
- 每个类和方法的潜在行为是否都有用简易的语言进行解释?否
- 方法和类的头注释是否和它们的功能保持一致?是
- 注释和代码是否保持一致?是
- 注释对于理解代码是否有帮助?是
- 代码中的注释是否充分?否
- 代码中的注释是否过多?否