一、我对下列关于编程规范问题的感想
1、这些规范都是官僚制度下产生的浪费大家的编程时间、影响人们开发效率, 浪费时间的东西。
不支持。
1）编程规范有利于自己提高编程效率和编程质量。编码是程序员的职责，一个好的信息技术产品必然有高质量的代码，高质量的代码首先
一点它必须遵守某种编程规范。如果你的源代码被作为产品发布，那么你必须保证它和其它产品一样很好的包装并保持整洁。
2）编程规范有利于别人迅速理解自己的代码。一个软件整个生命周期内成本的80%用于维护，几乎没有一个软件在整个生命周期内全部由它的原始作者来维护。编程规范改善了软件的可读性，使工程师更加快速、彻底的理解新代码。
3）提高了团队编程的效率。 大量数据表明，软件存在问题或者隐患，很大一部分是由于未遵守基本准则所致，如果能在项目早期明确规则，则会避免许多麻烦。为了简化工作，团队中每一个编写软件的人都必须遵守编程规范。
除此之外，每个人都习惯看自己的代码，如果团队中的成员能够统一编程的规范，那么大家阅读别人代码的时候就会更加有耐心。
2、我是个艺术家，手艺人，我有自己的规范和原则。
反驳。
个人的能力是有限的，一个成功的软件必然与团队中各个成员的努力密不可分。当一个团队共同开发一个软件的时候，每个人都必须遵守共同的编程规范。否则自身个性的编程规范会对团队中的其他成员阅读代码造成障碍。
3、规范不能强求一律，应该允许很多例外。
反驳
既然是规范，就必须制定清楚、并且每个人都要遵守。比如，在同一项目组应明确规定对接口函数参数的合法性检查应由函数的调用者负责还是由接口函数本身负责。对于模块间接口函数的参数的合法性检查这一问题，往往有两个极端现象，即：要么是调用者和被调用者对参数均不作合法性检查，结果就遗漏了合法性检查这一必要的处理过程，造成问题隐患；要么就是调用者和被调用者均对参数进行合法性检查，这种情况虽不会造成问题，但产生了冗余代码，降低了效率。
《快速软件开发》中指出，一个软件的稳定性往往比其功能更重要，一旦团队成员的代码衔接出现漏洞，软件的不稳定性就会极高，从而影响到整个软件的效果。
4、我擅长制定编码规范，你们听我的就好了。
反驳。
编码规范的目的在于提高整个团队的编码效率，因此除了合理性，应当符合绝大多数成员的编码习惯。如果你使用的编码规范并不是为你的项目专门设计的，它对你的项目也许并不是最佳方案。。同样，这只是语法：非最优并不表示是不好。也许对你的项目来说它不是最理想的，但并不能表明它不值得遵守。不错，对于你的项目，你并没有从中获得该有的好处，但对于一个大型公司来说，它带来的好处是巨大的。除此之外，专门针对某个项目制定编码规范一般效果会更好。一个项目拥有自己的编码风格无可厚非。
二、代码复查
Code Review Checklist
General
- Does the code work? Does it perform its intended function, the logic is correct etc.
- Is all the code easily understood?
- Does it conform to your agreed coding conventions? These will usually cover location of braces, variable and function names, line length, indentations, formatting, and comments.
- Is there any redundant or duplicate code?
- Is the code as modular as possible?
- Can any global variables be replaced?
- Is there any commented out code?
- Do loops have a set length and correct termination conditions?
- Can any of the code be replaced with library functions?
- Can any logging or debugging code be removed?
Security
- Are all data inputs checked (for the correct type, length, format, and range) and encoded?
- Where third-party utilities are used, are returning errors being caught?
- Are output values checked and encoded?
- Are invalid parameter values handled?
Documentation
- Do comments exist and describe the intent of the code?
- Are all functions commented?
- Is any unusual behavior or edge-case handling described?
- Is the use and function of third-party libraries documented?
- Are data structures and units of measurement explained?
- Is there any incomplete code? If so, should it be removed or flagged with a suitable marker like ‘TODO’?
Testing
- Is the code testable? i.e. don’t add too many or hide dependencies, unable to initialize objects, test frameworks can use methods etc.
- Do tests exist and are they comprehensive? i.e. has at least your agreed on code coverage.
- Do unit tests actually test that the code is performing the intended functionality?
- Are arrays checked for ‘out-of-bound’ errors?
- Could any test code be replaced with the use of an existing API?
You’ll also want to add to this checklist any language-specific issues that can cause problems.
The checklist is deliberately not exhaustive of all issues that can arise. You don’t want a checklist, which is so long no-one ever uses it. It’s better to just cover the common issues.
Optimize Your Checklist
Using the checklist as a starting point, you should optimize it for your specific use-case. A great way to do this is to get your team to note the issues that arise during code reviews for a short time. With this data, you’ll be able to identify your team’s common mistakes, which you can then build into a custom checklist. Be sure to remove any items that don’t come up (you may wish to keep rarely occurring, yet critical items such as security related issues).
Get Buy-in and Keep It Up To Date
As a general rule, any items on the checklist should be specific and, if possible, something you can make a binary decision about. This helps to avoid inconsistency in judgments. It is also a good idea to share the list with your team and get their agreement on its content. Make sure to review the checklist periodically too, to check that each item is still relevant.
Armed with a great checklist, you can raise the number of defects you detect during code reviews. This will help you to drive up coding standards and avoid inconsistent code review quality.