系统代码修改规范1

系统代码修改规范是为了确保在基于原厂公版代码进行修改时，能够保持代码的一致性、可读性和便于维护。规范主要针对三个核心方面：TAB处理、回车换行的处理以及修改的识别。 1. **针对TAB处理**： 在代码中，为了保持对齐的一致性，所有用作对齐的TAB键应被替换为空格。这是因为不同编辑器对TAB的解析可能存在差异，可能导致对齐混乱。因此，使用UE编辑器后，务必执行“格式/转换制表符为空格”的操作。对于原厂代码中已存在的TAB问题，修改时也应一并转换。 2. **针对回车换行的处理**： 系统代码通常在Linux服务器上编译，因此应当使用Unix风格的换行符。由于很多人在Windows环境下编辑代码，可能会引入Windows风格的换行符（表现为git diff时行尾的^M字符）。使用vim编辑器也能发现这类问题。因此，使用UE编辑后，应确保将代码转换为Unix格式，并在提交前进行检查。原厂代码中若存在此类问题，也应在修改时转换。 3. **修改的识别**： 为了便于他人识别出哪些修改是由谁完成，为何修改，以及修改的范围，需要添加特定的标识。对于单行修改，可以在注释中写明“//steven: comments for change.”；对于多行修改，可以使用如下的格式：“// steven: comments for changes. {codes added} // steven: end”。这种方式适用于C/C++和JAVA代码，同样适用于脚本的修改。在以下情况下，可以不另外增加识别： - 如果修改的位置已经由其他人修改过，直接在git提交信息中说明即可。 - 自行修改的代码必须添加识别，防止在合并代码时被覆盖。 - 合并原厂的patch时，如果是针对单个问题的小型修改，必须添加识别；如果是大量文件或内容的批量patch合并，可以不加，但需在git提交信息中详细说明。 通过遵循这些规范，可以提高代码质量，降低维护成本，同时便于团队协作和问题追踪。在实际操作中，每个开发者都应养成良好的代码修改习惯，以保持整个项目代码库的整洁和有序。