关于编码流程和风格的一点小总结

协议增加字段

以 star_def.xml 为例

3311 表示最后提交协议的版本号，每个版本号对应具体的一次提交，直接将责任下发到具体提交人。

正式编码前，通过 p4 update 拉取最新代码，并进入 protocol 目录执行

$ cd protocol

# 更新所有协议版本
$ ./update_version.sh xavierqiu

# 同时指定协议号
$ ./update_version.sh xavierqiu 3312

更改完协议后，将整个 protocal “edit” 状态加入changelist，并且revert unchanged file，一般是修改了包含 star_def.xml 在内的 8 个协议文件

编码需要注意的地方

2022-05-16 总结

  1. 最好先提交协议再提交代码，代码review过程需要较长时间，在这个过程中协议号可能会发生变化。
  2. 尽可能提取公共函数，减少代码冗余
  3. 编码中禁止使用危险函数。
    • 禁止使用 strcpy wcscpy lstrcpy strcpy tcscpy _ftcscpy mbscpy 应替换为 strncpy wcsncpy lstrcpyn _tcsncpy _ftcsncpy _mbsncpy
    • strcat wcscat lstrcat strcat _tcscat _ftcscat _mbscat 应替换为 strncat
    • vsprintf vswprintf wvsprintf wvnsprintf _vstprintf 应替换为 _vsnprintf _vsnwprintf _vsntprintf
    • sprintf swprintf wsprintf wnsprintf _stprintf 应替换为 _snprintf _snwprintf _sntprintf
    • gets _getws _getts 应替换为 fgetws fgets
  4. 修改协议时需要注意类型，应该用 uint64_t 的地方不要用 int，注意看数据的传递流程
  5. 打日志时，uint64_t 的占位符为 %“PRIu64”
  6. review时要加上文件负责人，通过 查询文件 owner。可以直接查询 change 号。

2022-06-23 总结 (新增任务类型合并需求)

  1. 编码风格统一 (可以通过 .clang-format 解决)
  2. 链路日志，程序执行的每一条链路的终止都需要打日志(其实就是每次return?)，而且日志尽可能表达完整信息
  3. 注意指针判空，尤其是review之后函数发生改动
  4. warn级别以上日志需要确认，小心刷屏
  5. 宏和相关枚举尽可能不要自己新定义，去macro和keywords找已经有的
  6. 可以提前返回的地方就直接返回，并打日志
  7. 不要混用值和错误码
  8. 涉及到 uint 尽可能不要用减法，用加法，避免溢出
  9. 单侧过滤 ./runUnitTests --gtest_filter=FRUSTRATION*

2022-07-13 总结 (参团率精度修复、AFK惩罚配置优化)

  1. 尽可能抽象出工具函数，业务弱相关，方便单侧
  2. 沟通问题：关于某个具体的问题，比如说IDIP侧和服务端哪个先更新的问题，需要多方确认后再进行编码和方案设计 3.

总则

不推荐过度设计

过度设计会导致代码复杂度增加，不方便阅读和维护。代码设计应该尽可能简单明了，避免过度抽象和复杂的设计模式。

常见流程需要进行文档化和规范化

沟通

C 规范

禁止使用危险函数

在 C 语言中，使用一些危险函数可能会导致缓冲区溢出等安全问题，因此需要避免使用这些函数。以下是一些常见的危险函数及其替代方案：

C++ 规范

不要使用 auto

auto 是 C++11 引入的关键字，用于自动推导变量的类型。auto 在个人项目开发时可以简化开发复杂度，但是在团队协作开发时，auto 会导致代码可读性下降，不利于团队成员之间的代码 review。一般还是更推荐使用显式类型声明，尤其是对象实例化的时候，方便后续扩展和维护。

不要使用 this->

this-> 是 C++ 中的一个关键字，用于指代当前对象的指针。在成员函数中，this 指针是隐式存在的，不需要显式使用。使用 this-> 会导致代码可读性下降，不利于团队成员之间的代码 review。

类定义中不要出现多个 public/private/protected 关键字

Golang 规范

proto 规范

不使用 required 关键字

使用 optional 和 repeated 关键字，即使是在 proto2 中也不能使用 required 关键字。

required 在 proto2 以前是存在的，但是在 proto3 中已经被废弃，一般也没有使用的必要。使用 required 会导致字段必须被设置，可能会导致版本兼容性问题。

命名时注意要体现含义

比如 suggested_request_interval

python 规范

Reference