标签：变量 netcore 编程 规范 注释 Pascal 命名 public 下划线
我理解的编码规范：
一、准则
1.编码规则
Pascal：UserName
驼峰：userNameAndPwd
全小写(下划线)：flower , user_name_pwd
全大写(下划线):NAME , SEO_TAIL
2. 命名要有意义
|
示例 |
|
|
Int price=20; |
√ |
|
UserInfo userInfo=GetUserInfo(userId); |
√ |
|
Int p=20; |
× |
|
Int intPrice=20; |
× |
3.对于类的成员变量，用this关键字，增强代码可读性。
4.对于基类的成员变量，用base关键字，增强代码可读性。
二、规范原则
1. 命名空间
命名空间采用Pascal命名法：
namespace Fw.Application{}
namespace Fw.SmartFlow.Acitivity{}
实际工作中，我们会将很多逻辑上属于同一类的文件，在物理上分成不同的目录，这时建议修改命名空间为相同的命名空间。
2.类
类采用Pascal命名法：
public class UserService{}
类是对属性和方法的封装，类有很多的种类：
- 跟数据库表对应的实体类
- 处理业务逻辑的业务类
- 提供扩展方法的扩展类
- 接口层的数据传输类
不同的种类可以约定俗成地进行一些名称的约束，比如扩展类用 Extension 结尾、接口层的使用 Request、Response 结尾，等等，这样在阅读代码是就知道什么类型的职责是什么。
注意：
（1）UI层与业务层交互，取名后面 +Dto
（2）数据库实体，类取名为 MO
（3）逻辑实体，既不与 UI交互，也不是数据库实体，是独立 的实体 BO
（4）Dto和MO中，属性是 可以包含 BO的。但是 DTO中属性不包含MO;MO中也不可以有DTO;BO中也不包含DTO和MO
3.接口
接口采用大写I+Pascal命名法：
public interface IUserService{}
异步接口 IAsync+Pascal 命名法：
public interface IAsyncUserService
4.方法
方法采用 Pascal 命名，方法本身能有意义。
方法的命名需要比较具体，越抽象的名称越难以理解。例如，InitData() 就是一个不太好的名称，改成 InitConfiginfo() 会更好些。另外，方法的命名在同一类型的语义下要保持一致，在一些项目中看到查找 类的方法，有 GetXXX、QueryXXX、FindXXX 等等。五花八门的方式会提升阅读的成本。
5.变量
变量分为：类变量、静态类变量、只读变量、静态只读变量、方法变量。
类变量：
private string _userName;
类变量只能使用 private 修饰符，如果需要暴漏出去，或是给子类使用，使用属性来进行封装。
静态类变量、只读变量、静态只读变量：
private static readonly ResourceManager _resourceManager;
public static readonly IRouter Instance = new MockRouter();
• 修饰符为 private: _ + 驼峰命名法；
• 修饰符为 public: Pascal 命名法；
• 修饰符为 protected：Pascal 命名法；
方法变量：
bool isCheck;
6.常量
常量采用 全大写（下划线）
public const string NAME = "";
public const string CENTER_PWD="";
7.属性
属性采用 Pascal 命名法.
public BasicApiContext DbContext { get; }
数据库实体类(MO)中的属性采用 全小写(下划线)
Public string user_pwd{get;set;}
注意：这样做是为了让数据库维护更能保持一致，特别是团队小型的情况下，反倒容易看得清楚，不会产生歧义。 数据库中的字段也用小写下划线形式。 以前开发，数据库操作基本是写sql， 字段有下划线会 编写困难。但是现在基本都用 全能ORM，基本不用考虑 sql的复杂度了。我个人觉得， 小写下划线的形式，反倒方便维护。
8.参数
参数采用驼峰命名法：
public List<BizApp> GetBizAppList(string userId,DeviceType deviceType)
三、注释规范
注释是一把双刃剑，当代码中存在大量的注释的时候，我们第一反应会先看注释，并会默认注释中写的内容是对的，真实情况是注释往往会给我们错误的指导。有两个原因：
- 当代码逻辑放生变化时，只修改了代码，注释没有调整；
- 不同的人员都对注释进行编辑，慢慢注释会变得和代码不匹配。
Martin Fowler 在他的经典书籍 《重构》 中也提到过多的注释是一种坏味道的体现，他认为，当你觉得需要写注释的时候，应该先想想是不是可以进行重构。那是不是程序中就不应该出现注释呢？当然不是，我认为下几种情况是需要写注释的：
- 时间紧急，临时写的一些 ”烂代码“，需要写注释，说明原因，一般需要加上 TODO ；
- 复杂算法类的方法，可以写注释说明逻辑；
- 写的是偏底层的类库，对外暴露的方法需要写注释，调用方能方便在智能提示中显示；
- 如果你的能力写不好代码，那还是先把注释写上吧。
（注意，参考来源：dotNET Core：编码规范 - oec2003 - 博客园 (cnblogs.com)）
标签：变量,netcore,编程,规范,注释,Pascal,命名,public,下划线 来源： https://www.cnblogs.com/zytfuture/p/15662705.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。