[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形式）
