代码复审
A.代码复审
概要部分
- 代码能符合需求和规格说明么？
符合 - 代码设计是否有周全的考虑？
不能说是周全，应该是经过一段时间的思考设计后再开始写的，不过有很多细节没有提前想到。 - 代码可读性如何？
有部分变量命名和函数名不大易懂，经过交流得到了改善
具体问题和交流过程见git https://github.com/ZiJiaW/Sudoku/issues/1 - 代码容易维护么？
功能做了一定的模块化，连接比较清晰，核心算法不是非常复杂，但是实现是全部在一个函数里，递归终止的条件和返回值的意义有些让人难懂 - 代码的每一行都执行并检查过了吗？
对
设计规范部分
- 设计是否遵从已知的设计模式或项目中常用的模式？
直观感觉上，设计较为合理，除了一些封装的问题和局部的代码存在冗余的问题。 - 有没有硬编码或字符串/数字等存在？
有，已解决 - 代码有没有依赖于某一平台，是否会影响将来的移植（如Win32到Win64）？
暂且没有 - 开发者新写的代码能否用已有的Library/SDK/Framework中的功能实现？在本项目中是否存在类似的功能可以调用而不用全部重新实现？
存在，其SudokuMaker和SudokuSolver类采用了相同的数据结构和类似的算法，可以考虑合并其功能以重用代码。 - 有没有无用的代码可以清除？（很多人想保留尽可能多的代码，因为以后可能会用上，这样导致程序文件中有很多注释掉的代码，这些代码都可以删除，因为源代码控制已经保存了原来的老代码。）
存在代码的类似及重复，但这是设计上的原因，可以清除但不损失功能的代码不存在。
代码规范部分
- 修改的部分符合代码标准和风格么（详细条文略）?
大部分已经符合，部分变量名没有完全更改
具体代码部分
- 有没有对错误进行处理？对于调用的外部函数，是否检查了返回值或处理了异常？
有，部分的file指针没有检查，没有异常的抛出 姑且不必处理 - 参数传递有无错误，字符串的长度是字节的长度还是字符（可能是单/双字节）的长度，是以0开始计数还是以1开始计数？
没有 - 边界条件是如何处理的？Switch语句的Default是如何处理的？循环有没有可能出现死循环？
- 有没有使用断言（Assert）来保证我们认为不变的条件真的满足？
没有 - 对资源的利用，是在哪里申请，在哪里释放的？有没有可能导致资源泄露（内存、文件、各种GUI资源、数据库访问的连接，等等）？有没有可能优化？
有存在泄漏情况，详情见 https://github.com/ZiJiaW/Sudoku/issues/2 有可能优化 - 数据结构中是否有无用的元素？
存在一些微小的问题
效能
- 代码的效能（Performance）如何？最坏的情况是怎样的？
使用了回溯法求解数独，性能一般 - 代码中，特别是循环中是否有明显可优化的部分（C++中反复创建类，C#中string的操作是否能用StringBuilder 来优化）？
有
for (auto p = ProblemSet.begin(); p != ProblemSet.end(); ++p, ++i)
{
SudokuSolver solution;
solution.ProblemInit(*p);
if (!solution.StartSolving())
{
cout << "No Solution in problem NO." << i + 1 << endl;
return 0;
}
int(*r)[9] = solution.getSolution();
for (int k = 0; k < 9; ++k)
{
for (int l = 0; l < 9; ++l)
{
result[9 * k + l + 81 * i] = char(r[k][l] + '0');
}
}
}
该循环中getSolution函数会申请新的内存来存放解，而这一步可以通过在循环外部建立静态缓存来优化
- 对于系统和网络调用是否会超时？如何处理?
不存在可能超时的调用
可读性
- 代码可读性如何？有没有足够的注释？
一般，有些变量的意义没有给出注释，有些变量的定义和使用相隔较远
可测试性
- 代码是否需要更新或创建新的单元测试？
需要
B.设计一个代码规范
1.工具提供的代码规范和你个人的代码风格有什么不同？
- 库头文件写在工程头文件前面
- 使用using-declarations 而不是 using-derectives
- { 写在前一行结尾
- 不使用tab 而使用空格
- 不在代码块内留空行
- , { , != , +之前留空格
2.工具提供的代码规范里有哪些部分是你之前没有想到的？
除了tab和大括号的用法之外都没有留意过
3.为什么要这样规范？这样的规范有意义吗？
使得不同的程序员写出来的代码不会差异太大，在进行团队合作时更有利。也使个人的代码风格更为规范，但是像“{”加在前一行尾还是新开一行的问题就显得没多大意义。
4.代码规范
- 缩进用空格
- 单行长度不超过80
- if分支全部使用大括号
- 大括号独占一行
- 多条语句分行
- 类/函数名使用Pascal，变量名使用lowerCamel
- 类成员的申明先public后private
- 函数重载不能让人不清楚其语义
