（part1）
原谅我的思绪再一次天马行空了，看完了博客里面的几个链接后最先投射到脑海中的不是Google，不是strict coding standards，而是2012年的奥运会的足球决赛。这场决赛过后，当时我所以为的毫无悬念的冠军--“巴西队”意外地输掉了这场比赛，当然，也许“意外”这个词只是对我而言的，相对于老牌的球迷们而言，群星璀璨的巴西队已经三度屈居亚军了。也是从那个时候起，十几岁的我的心里有了这样的一个朦胧的意识，那就是强强联手并不一定等于最优。
今天看了这三篇关于编程规范的文章，当年的思绪又升腾起来，其实思想这种东西吧就必须经过反刍才能纯化出完全的营养。现在回味文章中的想法其实也是在暗示代码界的个性选手们，或者说是喜欢张扬个人风格的精英们代码规范所规范的不只是个性，更是软件的诞生和成长的历程，从思想的角度来讲，它规范的是程序员们的大局观和集体意识，或者说是一种社会性的修为和素养。
接下来要说的就是我个人对一些关于代码规范观点的看法：
（观点一）：这些规范都是官僚制度下产生的浪费大家的编程时间、影响人们开发效率, 浪费时间的东西。
这个观点满是鼠目寸光的浮躁心理和无理取闹的暴民心态。这样说是因为我认为程序员书写代码的过程就像是翻译家翻译著作一样，只不过程序员的工作不是one human language to another human language，而是human language to machine language。而且两者有一个非常重要的区别就是翻译家可以一个人十年磨一剑，留下如椽巨笔，但是当下的社会却不太允许一个程序员十年磨一剑，创造出一个完全由他自己写就的程序，于是对于程序员而言，他的“翻译”的工作就多了“合作”这个几乎是不可缺少的环节。试想一下，如果每一个程序员都有自己的独到的遣词用句的个性和谋篇布局的想法，那么程序应该就像是许多个人合伙完成的文章，除了蹩脚和晦涩应该不剩什么了吧，就像我很难想象余秋雨和莫言按照自己的个性一人一句写成的文章一样。规范不仅不是阻碍开发，浪费时间的邪物，反而是促成效率成就未来的好东西。就像是某些算法中的局部最优不一定能导致全局最优一样，我们关心在意的是一个整体，所有看似平庸的局部也许就是达到全局最优的关键，而代码规范就是这个道理，看似限制了个性选手们的技能发挥，其实是“码农”之爱“代码”，必为其计之深远。
（观点二）：我是个艺术家，手艺人，我有自己的规范和原则
这个观点中的个人自我主义很严重。艺术家和手艺人可以有自成一家的个性，程序员也可以有不拘一格的风格，但是就像前面所说的那样，如果必须要合作呢？我们可能很难接受一个人长着毕加索画风的脑袋，披着吴冠中画风的长袍的“艺术”人物来。程序的成长亦如是，古语有言：“规矩方圆”。没有严格的规范，很难有完美的作品。艺术家们也是在继承和沿袭的基础上推陈出新的，而他们所继承的和沿袭的就是他们行业界的规范和原则，同理，程序员们的代码也是要相互传承，甚至是要相互合作的，于是在这种基础上对于规范和原则的坚守就显得更为关键了。
（观点三）：规范不能强求一律，应该允许很多例外
规范确实不能强求一律，规范确实也可以允许例外。法律这种规范已经够严格了吧，但是还是有基于道德之上的宽宥。可是很多例外这种事情就不能忍了，很多例外那么规范岂不是就被束之高阁而置若罔闻了吗？如果真的有很多的例外，那么例外就成了“规范”，那么程序员们的编程状态不就又回到了前面两个观点所描绘的“个性张扬”，“龙飞凤舞”的原始状态了吗？因为规范而逐渐演化而来的进步的意义不就重新回到原点了吗？借用《构建之法》里的一个词来讲，这种现象就叫做出现了退化吧。于是言而总之，例外应该尽最大的所能去避免。
（观点四）：我擅长制定编码规范，你们听我的就好了
这种心态和观点二是雷同的，都是有比较强的个人主义色彩。就像是博文的链接中说的那样：“在代码审查中最常犯的错误——几乎每个新手都会犯的错误——是，审查者根据自己的编程习惯来评判别人的代码”。太自我很容易犯错，一人一世界的心态容易导致人与人之间的壁垒，同样就像链接中的文章所说的那样：“按照自己的意愿去书写代码的程序员就像动物世界里的狗撒尿一样，创造了程序员之间的壁垒”。就像是一开始的我所联想的奥运会的足球比赛那样，每个人都有自己的个性球技，都想在这个过程中展示出来从而达到个人最优，但是结果呢？ 真的达到了结果的最优吗？显然没有。于是，合作的过程中不需要每个人都是创造家，更不需要每个人都是领头羊，更需要的是踏踏实实，和follow一个共同认可的规范。
综上所述，规范从形式上来看是规范个性，但是从意义上来看却是规范了软件的未来。
（part2）
代码复审表格
|
程序的正确性 |
程序运行时的命令行参数的传入有问题，数字没有正确传入，修改后就可以跑了 |
|
程序代码的规范性 |
程序中的标识符的命名和缩进等都很不错哦，读起来的感觉很好。 |
|
代码的模块化程度 |
程序中函数的功能分配比较好，函数内部没有冗余，这一点做的比我好，我有冗余。 |
|
程序的注释情况 |
程序一开始的函数中有很好的注释，但是后来的注释比较少，好吧，其实我也有这个问题。 |
|
程序对于异常的处理 |
程序并没有对所有的代码执行情况给出处理，尤其是对于异常的输出情况没有给出很好的处理导致程序会出现崩溃。 |
|
程序对于非法参数的处理 |
非法参数的输入也没有得到很好的处理，同样可能导致程序的崩溃，但是细细反思，我的好像也没有。。。 |
|
错误情况的捕捉 |
虽然c++中提供了try和catch 的异常处理机制，但是程序并没有很好地体现出这一点优势。 |
|
全局变量的可替换情况 |
程序中定义了一个输出文件的全局变量，这个变量其实是可以在程序中换成临时变量。 |
|
代码可被库函数代替情况 |
程序中的代码都必要的，暂时没有发现可以被标准的库函数替代的代码片段。 |
首先不得不说的是我的partner的代码结构很好的，非常容易读懂，要说的几点具体细节如下：
可以被替代的全局变量：
程序中一开始传错了命令行参数，这个是修改正确之后的代码：
程序中的value类的设计在如何区别不同类型的数值上不够方便，可以用一个变量的不同的值来表示：
除此之外就没有什么要说的啦，很赞~