个人作业week2-代码复审

一、代码复审Check List

1.概要部分

  • 代码能符合需求和规格说明么?
    代码实现了生成数独和求解数独的基本功能,在合法输入下,能够输出合法的数据。
  • 代码设计是否有周全的考虑?
    在生成数独的问题下,使用正则表达式匹配输入,同时对前置正号的输入也进行了支持;在求解数独的情况下,对于输入的数独谜题为合法谜题、残缺谜题都做了处理;代码没有对非-c,-s的参数进行处理,同时没有对参数个数进行处理。
  • 代码可读性如何?
    代码可读性一般,虽然可以看出很想让变量以及函数命名都有实际意义,但还是存在“拍脑袋”的命名方式,同时有的命名不明确,有误导倾向,导致代码更难理解。
  • 代码容易维护么?
    代码有基本的面向对象思想,也对一些功能进行了封装和模块化处理,也做到了成员属性的私有化,但是可移植还有一定距离。
  • 代码的每一行都执行并检查过了吗?
    有一些对数字异常处理的代码没有执行到,除此之外均执行一次,但在检查方面做的并不好。

2.设计规范部分

  • 设计是否遵从已知的设计模式或项目中常用的模式?
    有一些生成器模式的痕迹。
  • 有没有硬编码或字符串/数字等存在?
    有,但是可以看出是想要使用宏定义消除硬编码,但是实现效率不高,有的地方用了宏定义,有的地方就没用,由于生成数独方式的限制,会存入初始的数字数组。
  • 代码有没有依赖于某一平台,是否会影响将来的移植(如Win32到Win64)?
    在win64的平台上可以正常运行。
  • 开发者新写的代码能否用已有的Library/SDK/Framework中的功能实现?在本项目中是否存在类似的功能可以调用而不用全部重新实现?
    有一个行变换的方法是可以进行整合处理的,但是使用了许多的相似代码进行实现。
    github链接:https://github.com/wz111/sudoku_onlycode/issues/1
  • 有没有无用的代码可以清除?(很多人想保留尽可能多的代码,因为以后可能会用上,这样导致程序文件中有很多注释掉的代码,这些代码都可以删除,因为源代码控制已经保存了原来的老代码。)
    有些是之前查出来的bug,有些是为了做性能比较留下的代码。

3.代码规范部分

  • 修改的部分符合代码标准和风格么(详细条文略)?
    因为在结对编程之前,制定了新的代码规范,所以修改和编码都是按照新的代码规范来的,修改的部分符合代码标准和风格。

4.具体代码部分

  • 有没有对错误进行处理?对于调用的外部函数,是否检查了返回值或处理了异常?
    有一些简单的进行了处理,外部函数没有检查返回值以及异常处理。
  • 参数传递有无错误,字符串的长度是字节的长度还是字符(可能是单/双字节)的长度,是以0开始计数还是以1开始计数?
    目前暂未发现错误,字符串的长度是字符的长度,以0开始计数。
  • 边界条件是如何处理的?Switch语句的Default是如何处理的?循环有没有可能出现死循环?
    Default会返回错误信息,但并没有结束程序。循环不会出现死循环。
  • 有没有使用断言(Assert)来保证我们认为不变的条件真的满足?
    仅在单元测试中使用。
  • 对资源的利用,是在哪里申请,在哪里释放的?有没有可能导致资源泄露(内存、文件、各种GUI资源、数据库访问的连接,等等)?有没有可能优化?
    在处理开始进行申请,处理结束释放,没有发现问题导致文件资源的泄露,这一步的优化考虑的是在c++提供的多种输入输出函数中选取效率较快的代替之前的。
  • 数据结构中是否有无用的元素?
    没有。

5.效能

  • 代码的效能(Performance)如何?最坏的情况是怎样的?
    代码的性能满足测试需求,即在60s内处理1000以内的问题,但由于考虑到了随机性的问题,就牺牲了部分性能,生成1000000个数独在6-7s左右,求解10000个空白部分在36-54之间的数独要花费11s左右的时间,1000000个数独时间会更多,在300s以上。
  • 代码中,特别是循环中是否有明显可优化的部分(C++中反复创建类,C#中string的操作是否能用StringBuilder 来优化)?
    没有反复创建类,每个功能一个类,不会重复创建。String都用了c.str()进行转换,这里没有发现可以优化的部分。在其他功能的处理上可以优化,比如可以用确切的for循环来代替随机数。
    github链接:https://github.com/wz111/sudoku_onlycode/issues/2
  • 对于系统和网络调用是否会超时?如何处理?
    没有网络调用,未对超时进行处理,系统调用是测试时用来计时的,不影响核心代码结构。

6.可读性

  • 代码可读性如何?有没有足够的注释?
    可读性尚可,不过变量及函数命名还是不够精准表达含义,有的含糊不清,有的太过复杂。没有大段的注释。

7.可测试性

  • 代码是否需要更新或创建新的单元测试?
    单元测试还需要对void方法进行进一步测试,以及程序整体功能的连贯性检查。
  • 还可以有针对特定领域开发(如数据库、网页、多线程等)的核查表。
    目前没有。

二、设计一个代码规范

1.工具提供的代码规范和你个人的代码风格有什么不同?

工具提供的代码规范和我个人的代码风格基本一致,比如行末写左大括号、保留字后面要写一个空格等等。不过它所要求的更加全面,更加规范。

2.工具提供的代码规范里有哪些部分是你之前没有想到的?

工具所提供的代码规范检查的很细,行末空格都检查到了,这个我之前没有想到。还有就是要在代码的第一行加版权信息。

3.为什么要这样规范?这样的规范有意义吗?

这样的规范当然是有意义的,谷歌微软等大公司花费了不少精力制定了一份规范文档,并要求开发人员遵守这些约定,文档几乎涵盖了在编程中代码规范所涉及到的方方面面。这些大企业做这些工作一定不是给开发人员增添麻烦的,而是希望所有人员的代码在同一个代码规范下能够被更好的理解和维护。这就像遍布一个国家的铁路网络,所有的铁轨无论是高度、宽度,还是材质、硬度,都是完全一样的。在铺设铁轨的时候,因为各个地方的地理条件不尽相同,最适合的铺设方案都不一样,但铁路工人们也一定会把所有铁轨设计成一样的规格,尽管在最开始的施工时可能困难重重,但这却为日后的维修和保养带来了极大的便利。代码也是如此。每个程序员的代码风格都不一样,但大家都在做一个项目,都在一个团队里工作,看似条条框框的代码规范为日后的代码工作带来的好处时不能量化的。

4.请根据构建之法书上编码规范里提到的那些要点整理一份你们在结对编程时使用的代码规范。

代码风格规范

  • 缩进:4个空格
  • 行宽:100字符
  • 括号:在复杂的条件表达式中,用括号清楚的表示逻辑优先级
  • 每个大括号{,}都独占一行
  • 一行只有一条语句;一行也只定义一个变量
  • 命名:尽量简洁易懂,变量名称的第一个单词的首字母小写,后面单词的首字母大写;类名的单词首字母都大写,不使用下划线
  • 注释:只标记还需要做的部分。比如一块代码可以用更好但是更复杂的结构进行优化,但目前的做法也满足需求,则在这里进行标记。

代码设计规范

  • 函数:保证每个函数只实现一个功能,可以在多个模块中反复调用此函数
  • Goto:为保证程序逻辑的直观和易懂,不使用goto语句
  • 错误处理:在控制台输出错误信息,返回相应的返回值并退出
  • 类:类中均为私有属性,没有protected和public,方法均为public方法,私有属性命名前加下划线,方法命名使用动宾短语形式,采用驼峰命名法。
posted @ 2017-10-03 13:52  AlenDou  阅读(160)  评论(0编辑  收藏  举报