分析一套源代码的代码规范和风格并讨论如何改进优化代码

  个人工程实践主要任务为实现一个搜索引擎,所以我在github上找到了一个与我主题契合的C++搜索引擎开源项目-TypeSense作分析。git

  1. 源代码目录结构github

      该工程总体目录结构比较清晰,从上到下内容依次为:
docker

    .circleci:持续集成工具的配置文件框架

    assets:主要为软件Logo函数

    cmake: 管理工程构建,生成makefile工具

    docket:一系列dockerfile,用于生成docket镜像单元测试

    include:C++头文件测试

    src:C++源文件搜索引擎

    test:单元测试  spa

    此外根目录下还包含了一些构建工程用的Shell脚本、Cmake规则、README和许可证文件。能够看出整个工程目录结构属于比较常规的C++项目目录结构。

  

  2. 文件名/类名/函数名/变量名等命名 

  源代码文件名命名总体比较清晰,绝大多数文件看到命名能大概猜到是用于作什么的。命名大多使用了完整的有意义的英文单词,即便使用了英文单词缩写也属于计算机领域内经常使用缩写,如"cmd"->"command","exec"->"execute",令读者没有太多心智负担。

  源码中类名都使用了大写字母开头,函数名使用小写下划线命名,变量名使用小写下划线命名,宏名全大写,均为描述性名称,符合代码规范和风格通常要求。总体看起来基本清楚,名字容易让人理解。  

  可是类中private成员变量没有加下划线(不管是加在开头仍是末尾),这样作我认为没有加下划线看起来清晰。

    此外存在函数参数过多的问题,多达十几个参数,一长串参数调用起来也十分不便。

 

    建议把相关的参数打包成一个类,特别是一些配置参数能够打包成param类,比传一长串参数进去要好。OpenCV中就有相似作法:

    

  3. 接口定义规范  

  如图为该项目中的某个接口:

 

  我建议将接口类使用大写字母I开头来命名,或者以"Interface"结尾,这样能很容易地看出来是个接口类,符合清晰的原则。

 

  4. 单元测试组织形式  

  该项目使用的测试框架为Google的gest,这也是我写C++项目最经常使用的测试框架。能够看到做者把全部单元模块的测试代码以及测试用例文件都堆杂在一块儿,很难让人一眼看清楚哪些文件测试的是哪一个单元。

    改进建议:根据我阅读过的开源项目作法以及我本身践行的作法,通常是在整个test单元测试文件夹下为每一个单元测试单独创建新的文件夹,以此工程为例:能够创建array_test文件夹里面放入array_test.cpp以及其余依赖(或依赖的引用),创建store_test文件夹里面放入store_test.cpp及其依赖...  显然这样看起来会很清楚,哪些文件是用于测试哪一个模块的一目了然。

  5. C++项目代码规范和风格要求

  关于代码风格和规范其实有不少种,青菜萝卜各有所爱,一个团队内保持一致便可。我比较喜欢的C++代码规范和风格是Google内部使用的,如图:

  我在实践中也基本遵循这套规范,它使我代码看起来更加清晰,而且减小歧义。

相关文章
相关标签/搜索