我理解的编码规范：
一、准则
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)）