一、是否需要有代码规范
1、这些规范都是官僚制度下产生的浪费大家的编程时间、影响人们开发效率, 浪费时间的东西。
这个观点我不敢苟同。个人认为仅“影响人们开发效率”一句是对的。然而这句话有褒义有贬。影响自然有好的影响，也有坏的影响。所以说，就个人开发而言，刻板的遵循大众定义的代码规范确实会打断程序员的思考连贯性，以至减慢开发速度，降低开发效率。但是现实世界中，个人开发的现象越来越少，更多的是团队合作项目。这样就免不了几个人甚至数十人共享代码，整合代码。这样看来，统一的代码风格，规矩的代码规范，倒是会使拼接过程更加效率。采用相同的代码规范，也会使每个人可以用规范的思维方式很快的理解团队中其他人的代码。
所以说，就现实的发展趋势来看，有一个好的代码规范未必是件坏事。只是这个规范容杂度应该尽量的高，让编程人员可以保留小部分自己的风格，也不影响整体。
2、我是个艺术家，手艺人，我有自己的规范和原则。
严苛的说，这样的人不该出现在团队合作中。个性虽然是要保留的，但过分突出个性，就未免太过格格不入。不仅会影响团队合作效率，更甚者会与队员相处不来，造成人际关系破裂。这样看来，若还没有走到乔布斯，比尔盖茨这类人的的事业以及视野高度，我是不敢像社会发起挑战的。毕竟作为个体，我应该融入团体，适应团体。为团体考虑，做出一些不至于危及尊严的牺牲，未尝不可。
3、规范不能强求一律，应该允许很多例外。
这条我完全赞同。允许例外，但例外的也不能太突出。保留个性的同时，要尽可能的突出共性。这是团队合作更有效率的重要保障。
4、我擅长制定编码规范，你们听我的就好了。
人都是向着自己心中认为的“美”靠拢的。就我个人而言，若是看到了一个极“美”的代码风格，我自然会向之学习。然而每个人对“美”的理解又是不同的，这就是为什么不同的人会写出不同风格的代码，不同的代码中又会映射出不同角度的逻辑。这些都是不同的人心中的“美”。“编码规范”四个字如此生硬、刻板，而不敢说是哪个人心中的“美”。它体现的应该是“秩序”。这里的“秩序”不是个人的秩序，而是集体的秩序，集体的“美”。
集体的美应是每个人心中的一小块“美”拼成的。这样的东西，若是由个体制定，必然是不能形成“秩序”，反而会造成个体的不服从。所以我认为，编码规范，不应是盲从于某个人，而应由计算机发展至今的历史长河中，浓缩出的共性“美”拼接而成。
二、代码复审
General
1、 程序正常执行，完成了出题，算题和判题的功能，算法逻辑缜密。
2、 代码风格比较大众，逻辑严密，基本上可以读懂。
3、 与我的代码风格稍微有些许不同，例如大括号的位置。
4、 没有多余或重复代码。
5、 模块化不是很明显，但基本分块完成了功能。
6、 未在代码中找到全局变量，所以不存在替换问题。
7、 注释较少，建议比较核心的算法处应添加注释，帮助理解。
8、 没有多余的循环，每个循环都有限且有效。
9、 没有可被库函数替换的代码段。
10、有一段可去除的备用代码，如下图中注释部分。
Security
1、 根据代码，合法的输入数据测了多组，均正常。
2、 在代码中，未发现异常处理措施。
3、 输出经检验是正确的。
4、 按照合法输入给出确定的输入，不会出现无效参数。
Documentation
1、 没有程序说明（由于本程序作为作业形式给出，程序说明在作业要求中已经明确，不需要过多的说明）。
2、 没有功能说明（由于本程序作为作业形式给出，功能说明在作业要求中已经明确，不需要过多的说明）。
3、 当r数值较小，n数值过大时，即所给出的r值不足够产生n个计算表达式时，程序把可产生的表达式输出后，会处于空转状态，不会立刻停止。如 “–n 10000 –r 2”
4、 否。
5、 没有注释数据结构，且本题目不需要计量单位。
6、 代码中未发现未完成代码段。
Testing
1、 经测试，有一种情况（边界情况）未经处理。具体已在Documentation-3 中明确指出。
2、 测试数据已在作者第一次博客作业中给出，相对来说考虑较全面。
3、 作者给出的测试数据均表明程序正确运行，各功能正常。
4、 代码中仅使用了this指针，故不存在空指针和内存释放问题。
5、 经检验，未发现可被替换的测试代码。