[2017BUAA软工]第2次个人作业

软工第2次个人作业——代码复审



一、代码复审Check List

1.概要部分

  • 代码能符合需求和规格说明么?

    • 能正确处理题目要求,代码能符合需求和规格。
  • 代码设计是否有周全的考虑?

    • 能正确生成和解出数独,也能够处理错误参数等,考虑比较周全。
  • 代码可读性如何?

    • 可读性较差。
  • 代码容易维护么?

    • 可读性较差导致维护起来不太方便。
  • 代码的每一行都执行并检查过了吗?

    • 单元测试中有些代码没有执行到。

2.设计规范部分

  • 设计是否遵从已知的设计模式或项目中常用的模式?

    • 没有设计模式。
  • 有没有硬编码或字符串/数字等存在?

    • 有,一般在if的比较条件里出现。
  • 代码有没有依赖于某一平台,是否会影响将来的移植(如Win32到Win64)?

    • 不依赖。
  • 开发者新写的代码能否用已有的Library/SDK/Framework中的功能实现?在本项目中是否存在类似的功能可以调用而不用全部重新实现?

    • 没有。
  • 有没有无用的代码可以清除?(很多人想保留尽可能多的代码,因为以后可能会用上,这样导致程序文件中有很多注释掉的代码,这些代码都可以删除,因为源代码控制已经保存了原来的老代码。)

    • 没有。

3.代码规范部分

  • 修改的部分符合代码标准和风格么(详细条文略)?
    • 修改的部分代码标准风格一致。

4.具体代码部分

  • 有没有对错误进行处理?对于调用的外部函数,是否检查了返回值或处理了异常?

    • 对于输入错误的参数进行了处理,但并未对调用的外部函数检查返回值。
  • 参数传递有无错误,字符串的长度是字节的长度还是字符(可能是单/双字节)的长度,是以0开始计数还是以1开始计数?

    • 无错误,字节长度,以0开始计数。
  • 边界条件是如何处理的?Switch语句的Default是如何处理的?循环有没有可能出现死循环?

    • 边界条件通过判断分支处理,Switch中没有处理default,循环条件都加以控制了不会出现死循环。
  • 有没有使用断言(Assert)来保证我们认为不变的条件真的满足?

    • 没有使用断言。
  • 对资源的利用,是在哪里申请,在哪里释放的?有没有可能导致资源泄露(内存、文件、各种GUI资源、数据库访问的连接,等等)?有没有可能优化?

    • 资源一部分是在一开始申请为静态变量,余下的为函数内部栈空间的,文件一直打开没有关闭,可以将静态变量转化为动态变量进行优化。
  • 数据结构中是否有无用的元素?

    • 没有。

5.效能

  • 代码的效能(Performance)如何?最坏的情况是怎样的?

    • 代码性能较好,生成100w的数独只要1秒多,但解数独比生成数独要慢很多。
  • 代码中,特别是循环中是否有明显可优化的部分(C++中反复创建类,C#中string的操作是否能用StringBuilder 来优化)?

    • 用了大量的分支,可以通过数学的方法找到坐标对应的指定的3*3的小块,可以避免大量的代码。comment
  • 对于系统和网络调用是否会超时?如何处理?

    • 没有系统和网络调用。

6.可读性

  • 代码可读性如何?有没有足够的注释?
    • 代码可读性差,几乎没有注释。

7.可测试性

  • 代码是否需要更新或创建新的单元测试?

    • 单元测试可以多考虑几种情况,包括错误的测试,目前的单元测试只是考虑了少数情况,可以新增单元测试。
  • 还可以有针对特定领域开发(如数据库、网页、多线程等)的核查表。

    • 没有。

##二、设计一个代码规范
  • 工具提供的代码规范和你个人的代码风格有什么不同?

    • 没有发现版权信息
    • 制表符用空格代替
    • public:应缩进1空格在类里
    • 代码与注释之间有两个空格,//后应有一个空格
    • 代码块不应该有多余的空行
    • 每一行应少于80字符
    • }后面接else
    • 单参数的构造函数应标示明确
    • 不要直接使用namespace
  • 工具提供的代码规范里有哪些部分是你之前没有想到的?

    • 制表符用空格代替
    • 代码块不应该有多余的空行
    • }后面接else
  • 为什么要这样规范?这样的规范有意义吗?

    • 能提高代码的可读性,减少人与人之间的沟通成本
    • 有利于代码的维护和整合,一个团队必定有不少人需要写代码,若如风格迥异不但合并起来较困难之后的维护更是难
    • 有助于代码审查,代码审查能够帮助减少bug,提升代码质量
    • 可以减少bug,规范的代码能避免一些简单的bug,比如一些参数的规范异常检测等
  • 结对编程时使用的代码规范

    • 缩进使用4个空格
    • 行宽不能超过1000个字符
    • 只有一个语句的if等结构也要使用大括号,而且每个{和}都单独占一行,以增强可读性
    • 一行定义一个变量,不要在一行上写多个语句
    • 类型/类/函数名的每个首字母都大写(Pascal形式),变量的第一个单词小写其余首字母大写(Camel形式)
原文地址:https://www.cnblogs.com/lydiayang/p/7610907.html