Week 2 代码审查

我的伙伴是6班的小伙子潘礼鹏,经过几天的相处我觉得真的是说话很有趣的人,性格非常好,我们很划得来。

以下为我对他的代码的审查结果:

  1. VS2012与VS2013的兼容性

在这里写一个工具集的问题,不同的版本之间有着不一样的工具集,VS2012自带的工具集是VS2012(V110),而VS2013的工具集为VS2013(V120)。

改动这个也很简单,只需要在 选中项目,右键->配置属性->平台工具集->选择VS2013(V120)即可。

  1. 代码分析

潘同学的代码一共有两个文件,分别是

fenshu.cpp

SZYS.cpp

首先来看一下 fenshu.cpp

由于文件较大,我们截取一段。

void Fenshu::tongfen(Fenshu b)

{//按照b来放大a

fenzi = fenzi * b.fenmu;

fenmu = fenmu * b.fenmu;

}

void Fenshu::add(Fenshu b)

{

tongfen(b);

fenzi = fenzi + b.fenzi*(fenmu/b.fenmu);//防溢出

yuefen();

}

这个文件主要是实现对于所有分数的处理,比如加减乘除通分约分。

通过这一段程序我们能看出来:

  1. 该同学能够及时换行,代码的格式让人看起来很舒服。
  2. 该同学有加注释的好习惯,能方便队友更容易地上手他的代码。

不足之处:所有的变量名都是用中文标示的,这样看起来不是很舒服。

再来看一下SZYS.cpp

从名字来看我揣测SZYS是四则运算的意思。

tmpstr = getNumbString(numb[i + 1]);

if(op1[i] == "×")

{

tmp.mul(numb[i + 1]);

if(addsubKuohaoFlag(i,op1))

{

exercise = "(" + exercise + ")";  //考虑到*/优先级,无条件加括号

}

if(Random(2) == 0)  //0的话新加的在右边,1在左边

{

exercise += " × " + tmpstr;

}

else

{

if(muldivKuohaoFlag(i,op1))

{

exercise = "(" + exercise + ")"; //*/也有先后顺序

}

exercise = tmpstr + " × " + exercise;

}

continue;

}

if(op1[i] == "÷")

{

if(numb[i + 1].getFenzi() == 0 && tmp.getFenzi() != 0)

{

tmp.set(0,tmp.getFenmu(),0);

exercise = tmpstr + " ÷ " + "(" + exercise + ")";

}

else if(numb[i + 1].getFenzi() == 0 && tmp.getFenzi() == 0)

{

failFlag = true;  //除数被除数都为0,此时判定为生成失败,退回重新生成

break;

}

else

{

tmp.div(numb[i + 1]);

if(addsubKuohaoFlag(i,op1))

{

exercise = "(" + exercise + ")";

}

exercise += " ÷ " + tmpstr;

}

continue;

}

这个文件主要是处理逻辑。

在这段代码中,我发现:

  1. 各个flag没有什么意思,有点混乱。
  2. 起变量名的问题变得有些严重,比如addsubkuohaoFlag,让人看起来很费力气。
  3. 封装的不够,有500多行代码,有些方法有150多行。
  4. 分成了多个步骤,稍稍有一点繁琐。
  5. 最重要的一点,他的乘除号不是UTF-32编码的!这个在我运行程序对比时才看出来。

当然,也有很多优点:

1.       单元测试,程序运行完一个单元都会输出当前的状态,这样就立刻能知道是那个模块错了。我认为这个很重要!,也是我应该做的。

2.       定义了自己的类型,让逻辑变得简明易懂。

3.       考虑的十分全面,有很多关于优先级、括号的判断。这样也就是说基本功能实现的不错。

4.       每一个函数都有注释,可以快速理解他的思路。

5.       注重了内存,没有随便使用大数量的数组。我在第一版程序中使用了数组。后来用了List代替。

3.实际测验

实践出真知。

经过对这些运算的处理,发现了乘除号不属于 UTF-32编码!,其他的全都正确。

然后是测试对不同输入的支持。

  1. -n 100 -r 1 这种情况下会进入死循环。

说明没有对无法生成的情况做判断。

  2.–n 100 –r 10 输出正常,所有分数和0的输出符合要求。

  3.–n 1000 –r 100 跑了16秒,输入输出正常。

  4.–e xxx –a 输出对比正常。

4.时间复杂度分析

刚才说到1000 个跑了16秒,这是什么问题呢?我们启用代码分析。

后来我发现,主要是字符串的判重效率太低,占用了太多资源。

5.测试

这位同学在很多函数后面加了输出,也就是说他会在一些函数完成后给予成功信息,我认为这也是测试的一种很好的方法。

时间: 2024-10-14 06:28:57

Week 2 代码审查的相关文章

代码审查的重要性

前些天有人写了一篇超精彩的博客贴子,是关于之所以要将优秀的程序员从平庸的群体中挑选出来的重要性.这篇文章写得真的很好,因为它讲述的情况和产生的可怕后果,在我的职业生涯中我已经见得太多太多了,不过这其实是很容易阻止的. 作者讲述了这样一种现实情况--一家公司需要实施某个非常重要的模块,但是此时它的高级开发人员 Mr Senior 很忙.因此,他们将模块给了新手 Mr Newbie--他花了 4 个月来写模块,两个星期的时间来修复 QA 发现的大量 bug,浪费了技术支持无数个小时用于揪出 QA 没

代码审查

后续不断的补充代码审查的方法,心得 在实现的功能模块,按倒序的方法审查代码,能不同程度的欺骗你的大脑,去忘掉那些业务意义 在心里美美的朗诵代码,会发现一些问题的

代码审查工具

来自:coolshell Code Review中文应该译作“代码审查”或是“代码评审”,这是一个流程,当开发人员写好代码后,需要让别人来review一下他的代码,这是一种有效发现BUG的方法.由此,我们可以审查代码的风格.逻辑.思路……,找出问题,以及改进代码.因为这是代码刚刚出炉的时候,所以,这也是代码重构,代码调整,代码修改的最佳时候.所以,Code Review是编码实现中最最重要的一个环节. 长时间以来,Code Review需要有一些有效的工具来支持,这样我们就可以更容易,更有效率地

程序员必备的代码审查(Code Review)清单【转载】

在我们关于高效代码审查的博文中,我们建议使用一个检查清单.在代码审查中,检查清单是一个非常好的工具——它们保证了审查可以在你的团队中始终如一的进行.它们也是一种保证常见问题能够被发现并被解决的便利方式. 软件工程学院的研究表明,程序员们会犯15-20种常见的错误.所以,通过把这些错误加入到检查清单当中,你可以确保不论什么时候,只要这些错误发生了,你就能发现它们,并且可以帮助你杜绝这些错误. 为了帮助你开始创建一个清单,这里列出了一些典型的内容: 代码审查清单 常规项 代码能够工作么?它有没有实现

使用Check Style 进行代码审查——第五周作业

mkpad 使用Check Style 进行代码审查 之前写代码一般就主要关注运行的结果,对于代码编写的规范性并没有太在意,甚至有时候 还自认为自己的代码还是挺复合标准的,但是最近接触到一款用于代码审查的静态测试工具 ——Check Style,才彻底改变了我的想法. CheckStyle是SourceForge下的一个项目,提供了一个帮助JAVA开发人员遵守某些编码规 范的工具.在最新版的里提供了goole公司和Sun公司的代码编写规范.当然,该工具使用 的标准也可以是你自己建立起来的,你可以

项目代码审查地点

团队项目代码审查定在明天下午2:00-4:00,G1125.每个项目的审查时间控制在12分钟以内,按照下述顺序逐个检查. bestRW bugphobia Chronos 爱码室 Dream Power™ Team C# 歪果仁带你灰 窝窝头 软剑攻城队 主要检查步骤: 1. 从代码管理工具(github或TFS)上将最新版的代码同步到本地: 2. 编译代码为可执行程序: 3. 部署并运行程序.

代码审查时,发现功能实现的原因,而不仅仅是挑毛病(转)

对于很多公司来说,代码审查是开发人员日常工作中的重要环节.通过代码审查,可以及早发现项目中存在的问题.促进同事之间的沟通与交流,并且可以在讨论中迸发出智慧的火花.但要想成功实施代码审查却并不是一件轻松的事情,为什么要进行代码审查.何时做.如何做,这是摆在我们面前的3个重要问题.针对于这3个问题,开发者Lisa Tjapkes撰文谈到了自己的经验与教训. 在我最近的项目经历中,我们进行了广泛且正式的代码审查.这个过程极大地改进了项目的代码质量,降低了项目中新特性开发的等待时间,同时还促进了知识在整

代码审查工具Collaborator v10版本发布,新增强大的缺陷和错误跟踪功能

开发过程中的过载通讯 审核用户的需求和事故,扩团队沟通,从接口处提供高质量的软件.在于全球大多数分布式开发团队合作时,开发过程需要一个有效的反馈机制工具,确保在跨时区合作中不会有时间和速度的局限性. 代码审查--帮助建立更好的软件和团队 在你的代码审查流程中选择一个最适合你团队的方案.一个轻量级和可定制的对等代码审查工具,帮助减少错误代码并帮助你的团队不断提高交付效率.支持所有主要的SCM和IDE. 强大的缺陷和错误跟踪,为你节约大量时间 从长远来看,已经证明代码审查不仅节省时间和金钱,还可以帮

你们公司做代码审查吗?(转)

当从各种公司听到他们正在尝试自动化部署/测试的事情,我都非常关注,但通常会很吃惊,他们很少会考虑去实行代码审查制度. 看到这种情况,我通常想问:如果代码没有经过其它人的审查,你如何知道你要测试的是什么?这答案(如果有的话)通常是捏着手指头说有几个人在做代码审查或"正在考虑中". 没有代码审查?真的吗?不可思议?!? 代码审查不是可有可无的. 不论你采用什么形式的测试过程,什么形式的部署过程,没有代码审查--game over.为什么?因为代码的质量是一种人能看懂的质量.不管你如何测试,

**代码审查:Phabricator命令行工具Arcanist的基本用法

Phabricator入门手册 http://www.oschina.net/question/191440_125562 Pharicator是FB的代码审查工具,现在我所在的团队也使用它来进行代码质量的控制.其提供了一个differential(code review)命令行工具Arcanist(arc).本文仅从本人的日常使用中总结出Arcanist比较常用的用法做个简单介绍. 环境说明 OS: OS X Mountail Lion SCV: svn IDE: Eclipse 安装 将Ar