系列 | 内容 |
---|---|
规范 | 系统代码修改规范 |
规范主要是针对系统代码修改的, 分成三部分, 分别是针对 TAB
处理, 针对回车换行的处理, 修改的识别三个方面做出明确的定义要求。
1、针对TAB
处理
代码中,行对齐的 TAB
键, 要换成空格, 不允许直接使用 TAB
键。
原因: 是不同的编辑器对 TAB 的解释都不一样, 造成对齐的混乱。
所以: 在使用 UE 编辑代码之后, 记得使用"格式/转换制表符为空格"
这个在原厂的代码中可能本身就有这样的问题. 修改时碰到了, 就一并转换过来.
2、针对回车换行的处理
因为系统代码一般是在 linux
服务器上编译的。 换行符全部要使用 unix
的换行符。大家一般都是在 windows
下编辑修改代码的, 所以很容易出现 windows
换行符。
出现 windows
换行符时,在 git diff
时, 可以看到行尾出现^M
的字符. 这个可以做为检查修改的方法.
使用 vim
编辑器时也会显示这种^M
符号.
所以使用 UE
修改代码之后, 记得转换成 unix
格式.
3、修改的识别
增加修改的识别标识, 用于告诉其它人, 这个地方是谁,为什么修改, 修改的开始和结束位置.
这个的目的方便其它的针对公版代码对比查问题时, 方便区分哪些是我们自己做的修改, 哪些是公版更新的.
建议的识别:
单行:
//yang: commens for change.
多行:
// yang: commens for changes.
{codes added}
// steven: end
这两条都适用 C/C++
, JAVA
代码. 同样也适用于脚本的修改.
其它特殊修改说明:
- 如果修改的地方是其它人已经修改过的地方, 可以不另外增加识别. 直接修改, 在 git 提交信息中说明即可.
- 自行修改代码, 识别必需加. 防止别人合并代码时, 把你的修改合并掉了.
- 合并原厂提供的 patch, 如果是单个问题的 patch, 修改的文件/内容不多, 必需加.
如果是批量的 patch 合并, 修改的文件很多, 内容也很多. 可以不加. 但在提交的 git 信息中要说明清楚.