一.是否需要有代码规范
1.不同意该观点。每个人都有各自的代码风格，当单独工作时不会产生什么影响。但当进行团队项目合作时，正如文章中提到的面对“代码集体所有制”时，多样的风格变成了团队的阻碍。团队间的协作少不了代码之间的分配与合作，此时个人必须也应该服从于集体。统一的代码规范有助于统一的维护，也能减少队内纷争，从而让队伍更加团结有效率；而且也利于另一篇文章中提到的代码复查。所以制定一套合格的代码规范，根本不是一件浪费时间影响效率的事，事实正好相反。
2.不同意。对于软件工程中的团队合作这件事，个人的艺术天分不应该发挥在代码规范上，更不应该成为阻碍团队协作与成果的借口。代码规范是团队合作的基本保证，是整个团队保持一致性的关键。艺术天分完全可以用在其他方面。
3.不同意。不强求何来规矩？如果总是有例外的话，规范根本无法维持下去。法律不会给任何人“例外”的权利，代码规范对于一个团队同样如此。
4.不同意。代码规范是一个团队共同使用的，会对日后的项目工作产生巨大作用。经过团队共同商讨出的代码规范，往往会比个人决策出的代码规范更加合理，更能让大多数人满意，更有利于项目的后续进行。另外，团队合作毕竟是一个协作、磨合、相处的过程，有些事情“集中制”更加有效，有些事以民主的方式往往更好。
二.代码复审
参考http://blog.fogcreek.com/increase-defect-detection-with-our-code-review-checklist-example/给出的代码复审各项标准
（一）代码整体
1.代码是否能够正常工作？是否能够达到预期的功能，逻辑是否正确：未实现全部功能，实现了生成式子并运算的功能。将生成结果及答案写入txt功能为未实现。
逻辑正确性：（1）对于关于0生成限制不完善。 例：输入n=10 r=2，输出的式子中分子包含0。 0/1+0/1+0/1.
（2）计算部分有错误：关于连续减法、除法均有错误。 例：29-29-29=0
（3） 检测负数产生功能不完善。 例子同上
2.代码是否易于理解：代码结构分明，也有合适的注释，变量命名也规范，可读性强。
3.是否符合你们的代码规范？通常包括括号的位置，变量和函数的命名，每一行的长度，格式以及注释：在我自己看来符合自己能接受的代码规范，代码清晰。
4.是否有冗余代码：在Expression.cs中，分情况处理子表达式式时（多个combine方法），各种情况是有很大相通性的，可以将多个方法合并成一个，加控制变量控制即可
在SubExpression中也是一样，多个方法有相似性
5.模块化程度：划分代码时以表达式为划分核心，分为了Expression Expression SubExpression 等多个模块，模块化程度较高
6.全局变量是否能够被替代？：无全局变量
7.是否有被注释掉的代码：含有被注释掉的代码
8.循环是否设置循环长度以及是否可以正确结束：无死循环存在，循环均可正确结束
9.是否有代码能被库函数代替：对c#不太熟悉，库函数的了解不是很多。。。
10.可以删除任何日志记录或调试代码吗?:无日志记录和调试代码
（二）安全性
1.所有的输入/输出数据都被检查（检查格式是否正确，长度，类型以及范围等）并且编码过了吗？：输入参数未检查，当输入参数不合法时，未能正确处理给出错误信息。如输入-r 0，程序会直接不正常结束
输出方面此项目并未涉及检查。但能正确处理，输出分数对应组成部分
2.哪些地方使用了第三方程序，返回的错误信息是否全部被捕获了？：未涉及第三方程序
3.不合法参数：第1条中已提到，输入不合法参数未被处理
（三）文档
未涉及文档
1.是否有文档来解释代码？
2.所有的函数是否有加上规格？
3.是否对不寻常的行为或边界情况处理进行描述?
4.是否有记录对第三方函数的使用情况？
5.对数据结构和度量单位解释了吗?
6.有不完整的代码吗?如果是这样,应该是删除或标记等一个合适的标记“待办事项”?
（四）测试
1.代码是可测试的吗?即是否添加太多隐藏的依赖、是否能够初始化对象、测试框架可以使用方法等：代码可以进行测试
2.测试是否存在？以及它是否做到了完全覆盖？: 未设计测试代码
3.单元测试是否测试到了代码能否达到预期的功能？：未设计测试代码
4.哪些测试代码是可以用已经存在的API来代替的？：未设计测试代码
5.数组越界检查：并未进行数组越界方面的检查与处理，存在风险。
总结，性能上并不是十分理想，一些边界情况的处理不到位。但在代码规范上做的较好，而关于测试与文档环节，现在可能还并未涉及。