一、是否需要有代码规范。对于是否需要有代码规范，请考虑下列论点并反驳/支持：
1.这些规范都是官僚制度下产生的浪费大家的编程时间、影响人们开发效率, 浪费时间的东西。
我不赞同这种说法。现今软件开发已经不仅仅是一个人的工作，动辄上万行的代码是一个庞大的工程，一个好的软件从设计到实现再到测试，整个过程要求团队所有成员的通力配合，而不是某几个人的单打独斗。既然强调配合，就要考虑到团队的效率问题，代码规范就是用来保证团队效率的最有效手段之一。试想如果每个团队中的程序员都用自己的个性风格来写代码，当代码需要被其他人使用时，他人需要花费大量的时间去阅读他的代码，去熟悉他的风格，这将造成一笔极大的时间开销。如果大家都按照统一的规范去完成自己的代码，这样不单给了代码的使用者极大的方便，也给自己阅读代码带来了方便，从而有效地提高了整个团队的编程效率，省去了许多不必要的麻烦。
在我看来这就是一个tradeoff的过程，团队中的程序员可能会牺牲一些个性，会牺牲自己独特的风格甚至是更高效的代码，但是这样的牺牲带来的是整个团队编程效率的提高，是最终高质量软件的生成，相比之下，这样的tradeoff还是很划算的。
2.我是个艺术家，手艺人，我有自己的规范和原则。
我不赞同这个观点。好的程序员可以和艺术家媲美，他对于代码的创造力甚至不亚于艺术家对于颜色和线条的掌控。但是这并不意味着他可以完全像个艺术家一样为所欲为，因为程序编写毕竟是一项规范化的工作，它不同于可以完全自由发挥的艺术创作。如果仅仅是做一些小软件和个人项目，完全按照自己的规范去编写代码是没有问题的，然而在软件工程化方法中，一个好的程序员若想像艺术家一样创作出好的软件，他就必须遵守一些共同的编程规范，因为此时的软件开发已经不是他一个人的事情了。
3.规范不能强求一律，应该允许很多例外。
我不赞同这个观点。规范之所以称为规范，就是要给整个团队制定一个共同的规则和约束以保证效率。如果规范中有了太多的例外，这就势必会在同一规范下工作的程序员间造成不必要的困扰。一旦规范中允许了有个别例外，不同的人就会找不同的理由去为自己的例外开脱，长此以往会造成整个规范体系的崩溃。
4.我擅长制定编码规范，你们听我的就好了。
我不赞同这个观点。每个人都会有自己的编程习惯，我们很难说清孰优孰劣，一些特定的习惯可能会提高个人的编程效率。好的编码规范应该是综合考虑整个团队的编程风格之后的一个折中，这个规范尽可能地照顾了大多数团队成员的编程习惯。所以编码规范决不能仅仅由团队中的某个人制定，而应该是整个团队共同参与制定的结果。
二、代码测评
对同伴项目进行代码审查的结果：
|
Code Review CheckList |
|
|
General |
|
|
代码是否能够正常工作？ |
可以正常工作 |
|
所有的代码都简单易懂吗？ |
部分代码缺乏注释，难以理解 |
|
是否符合你们的代码规范？ |
并没有事先商量好代码规范 |
|
是否存在一些冗余或者重复的代码？ |
存在冗余代码，可以将特定功能写进函数以降低冗余 |
|
是否做到了尽可能的模块化？ |
模块化较差偏向过程化 |
|
有没有一些被注释的代码？ |
有 |
|
循环的长度是否规整？循环是否有正确的终止条件？ |
部分循环没有 |
|
Security |
|
|
所有的输入数据都被检查? |
否 |
|
第三方程序的使用？ |
未使用第三方代码 |
|
输出值是否经过了检验？ |
经过了检验 |
|
是否有对无效参数进行检验？ |
对部分无效参数进行了检验 |
|
Testing |
|
|
可测试性？ |
可进行单元测试 |
|
是否已经做了测试？ |
未做测试 |
|
单元测试的效果？ |
大多数单元模块运行正常 |
|
数组是否有越界？ |
否 |
评测总结
代码总体质量一般，由于未采用模块化的编程思想导致整体结构较乱，想要单独测试某个模块功能较难，建议之后采用模块化编程，同时优化代码结构，减少不必要的函数。