我的工程实践主要任务为实现一个搜索引擎，因此我在github上找到了一个与我主题契合的C++搜索引擎开源项目-TypeSense做分析。
1. 源代码目录结构
该工程整体目录结构比较清晰，从上到下内容依次为：
.circleci：持续集成工具的配置文件
assets：主要为软件Logo
cmake: 管理工程构建，生成makefile
docket：一系列dockerfile，用于生成docket镜像
include：C++头文件
src：C++源文件
test：单元测试
此外根目录下还包含了一些构建工程用的Shell脚本、Cmake规则、README和许可证文件。可以看出整个工程目录结构属于比较常规的C++项目目录结构。
2. 文件名/类名/函数名/变量名等命名
源代码文件名命名整体比较清晰，绝大多数文件看到命名能大概猜到是用于做什么的。命名大多使用了完整的有意义的英文单词，即使使用了英文单词缩写也属于计算机领域内常用缩写，如"cmd"->"command"，"exec"->"execute"，令读者没有太多心智负担。
源码中类名都使用了大写字母开头，函数名使用小写下划线命名，变量名使用小写下划线命名，宏名全大写，均为描述性名称，符合代码规范和风格一般要求。整体看起来基本清楚，名字容易让人理解。
但是类中private成员变量没有加下划线（无论是加在开头还是末尾），这样做我认为没有加下划线看起来清晰。
此外存在函数参数过多的问题，多达十几个参数，一长串参数调用起来也十分不便。
建议把相关的参数打包成一个类，特别是一些配置参数可以打包成param类，比传一长串参数进去要好。OpenCV中就有类似做法：
3. 接口定义规范
如图为该项目中的某个接口：
我建议将接口类使用大写字母Ｉ开头来命名，或者以"Interface"结尾，这样能很容易地看出来是个接口类，符合清晰的原则。
4. 单元测试组织形式
该项目使用的测试框架为Google的gest，这也是我写C++项目最常用的测试框架。可以看到作者把所有单元模块的测试代码以及测试用例文件都堆杂在一起，很难让人一眼看清楚哪些文件测试的是哪个单元。
改进建议：根据我阅读过的开源项目做法以及我自己践行的做法，一般是在整个test单元测试文件夹下为每个单元测试单独建立新的文件夹，以此工程为例：可以建立array_test文件夹里面放入array_test.cpp以及其他依赖（或依赖的引用），建立store_test文件夹里面放入store_test.cpp及其依赖... 显然这样看起来会很清楚，哪些文件是用于测试哪个模块的一目了然。
5. C++项目代码规范和风格要求
关于代码风格和规范其实有很多种，青菜萝卜各有所爱，一个团队内保持一致即可。我比较喜欢的C++代码规范和风格是Google内部使用的，如图：
我在实践中也基本遵循这套规范，它使我代码看起来更加清晰，并且减少歧义。