# xr_coding_standard **Repository Path**: Rinaloving/xr_coding_standard ## Basic Information - **Project Name**: xr_coding_standard - **Description**: 信软代码 - **Primary Language**: Unknown - **License**: Not specified - **Default Branch**: master - **Homepage**: None - **GVP Project**: No ## Statistics - **Stars**: 0 - **Forks**: 0 - **Created**: 2024-07-08 - **Last Updated**: 2025-02-05 ## Categories & Tags **Categories**: Uncategorized **Tags**: None ## README # 信软后端代码规范 ## 一、 命名 > 命名规则 项⽬中⼀律采⽤驼峰命名规则, _**禁止使用汉语拼音**_ 。骆驼式命名法就是当变量名或函数名是由⼀个或多个单词连结在⼀起, ⽽构成的唯⼀识别字时,第⼀个单词以⼩写字⺟开始;从第⼆个单词开始以后的每个单词的⾸字⺟都采 ⽤⼤写字⺟。 * ⼩驼峰法: 除第⼀个单词之外,其他单词⾸字⺟⼤写。 * ⼤驼峰法: 把第⼀个单词的⾸字⺟也⼤写了。 - **总体要义**: * 名字含义要明确,做到⻅名知义(禁⽤汉语拼⾳),如: User,Customer。 * 尽量少⽤缩写,必须确保能让⼈看懂含义。 > 规则明细 - **变量名**: 1. ⼩驼峰式命令,变量名⾸字⺟必须要⼩写字⺟,不使⽤ “_” 作为变量名(包括成员变量)开头 2. 使⽤英⽂作为变量名,若使⽤汉语拼⾳,必须注释清楚 3. 正确:userName,错误:UserName,_UserName,username - **常量名**: 1. 常量名必须全部为⼤写 2. 各单词必须以下划线分开,以便区分 3. 对于枚举类常量,添加 Description 属性 (名字⼩写) ![输入图片说明](%E5%B8%B8%E9%87%8F%E5%90%8D.png) - **⽂件夹命名规范**: 1. ⽂件夹命名以⼤驼峰法作为命名规范,例如:Common,⽰例图如下: ![输入图片说明](%E6%96%87%E4%BB%B6%E5%A4%B9%E5%91%BD%E5%90%8D%E8%A7%84%E8%8C%83.png) - **⽂件名命令规范**: 1. ⽂件命名以⼤驼峰法作为命名规范,实体类,Servivce 类,Dto 类等,⽰例图如下: ![输入图片说明](%E6%96%87%E4%BB%B6%E5%90%8D%E5%91%BD%E5%90%8D%E8%A7%84%E8%8C%83.png) - **公共函数命名规范**: 1. 公共函数以⼤驼峰法作为命名规范,参数以⼩驼峰法作为命名规范,⽰例图如下: ![输入图片说明](%E5%85%AC%E5%85%B1%E5%87%BD%E6%95%B0%E5%91%BD%E5%90%8D%E8%A7%84%E8%8C%83.png) - **异步函数命名规范**: 1. 异步函数以 Async 作为后缀,例如:SetStickAsync,⽰例图如下: ![输入图片说明](%E5%BC%82%E6%AD%A5%E5%87%BD%E6%95%B0%E5%91%BD%E5%90%8D%E8%A7%84%E8%8C%83.png) - **model 命名规范**: 1. 以 Entity 结尾,UserEntity ⼀张数据库表对应⼀个 Entity 类。⽰例图如下: ![输入图片说明](model%E5%91%BD%E5%90%8D%E8%A7%84%E8%8C%831.png) 2. ViewModel ,Dto(数据传输对象),对外(前端展⽰)以 Output 结尾,更新,插⼊以 Input 结尾,查询以 QuaryInput 结尾。⽰例图如下: ![输入图片说明](model%E5%91%BD%E5%90%8D%E8%A7%84%E8%8C%832.png) ![输入图片说明](model%E5%91%BD%E5%90%8D%E8%A7%84%E8%8C%833.png) ## ⼆、注释 > 注释要求 - **常函数体、类、接⼝、枚举**: 1. 必须填写注释信息,功能说明,参数说明,作者信息,编写时间。函数必须添加块注释⽰例图 1. 如下。 ![输入图片说明](%E6%B3%A8%E9%87%8A.png) 2. 代码注释不超过⼀⾏使⽤'//',超过⼀⾏使⽤‘/* */’。 3. 复杂代码逻辑必须有注释。 ## 三、排版 > 排版规范 - 单个⽅法⻓度尽量保持在 50 ⾏以内,最多不超过 80 ⾏。 - lambda 链式操作按条件换⾏。 ![输入图片说明](%E6%8E%92%E7%89%88.png) - 对⽣成⽅法使⽤region注解代码块,⽅便查看代码。 - 开发⼯具使⽤ Visual Studio Community 2022。 ## 四、代码提交 >提交规范 - 代码统⼀⽤极狐 GitLab 进⾏版本管理。 - 原则上完成⼀个完整功能并⾃测⽆异常后,⽅可 checkin(签⼊)代码,必须保证⽆编译报错。 - 提交代码必须写注释,能够完整描述本次提交变更的内容 。 ![输入图片说明](%E4%BB%A3%E7%A0%81%E6%8F%90%E4%BA%A4.png) ## 五、接⼝开发规范 >命名规范 - 接⼝名称要⽤能体现接⼝⽤途的名词或名词短语。例如:Disposable 。 - 接⼝名称应该是清晰、具有描述性,以便其他开发⼈员理解接⼝的⽤途。 >⽅法和属性 - 接口中的⽅法和属性应该具有清晰的名称,描述其功能。 - 接口⽅法不应包含实现代码,只是⽅法签名。 - 如果需要在接口中声明属性,它们应该只有 get 访问器或 set 访问器,或者两者都有,具体取决于 需要。 >显⽰接⼝实现 - 在实现接⼝的类中,如果多个接⼝具有相同名称的⽅法或属性,应使⽤显式接⼝实现来区分它们。 这可以通过在⽅法或属性名称前加上接⼝名称来实现。 - 显式接⼝实现可以防⽌命名冲突,同时允许类实现多个接⼝,每个接⼝都有⾃⼰的实现。 >版本控制 - 当需要对接⼝进⾏更改时,应该⾮常谨慎,因为这可能会影响到实现了该接⼝的所有类。如果必须 对接⼝进⾏更改,可以考虑创建新的接⼝,以保持向后兼容性,并逐渐迁移现有的实现。 >⽂档 - 接⼝应该有清晰的⽂档说明其⽤途、⽅法和属性的预期⾏为,以及实现接⼝的类应该遵循的契约。 >注释 - 在接⼝成员上使⽤注释,以提供更详细的说明和帮助其他开发⼈员理解接⼝的使⽤。 >命名空间 - 接⼝应该位于适当的命名空间中,以便组织和查找。