我理解的编码规范：

一、准则

　　1.编码规则

　　　　Pascal：UserName

　　　　驼峰：userNameAndPwd

　　　　全小写(下划线)：flower , user_name_pwd

　　　　全大写(下划线):NAME , SEO_TAIL

　　2. 命名要有意义

 　　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)）