netcore编程规范

2021/12/8 17:46:39

本文主要是介绍netcore编程规范,对大家解决编程问题具有一定的参考价值,需要的程序猿们随着小编来一起学习吧!

我理解的编码规范:

一、准则

 

  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编程规范的文章就介绍到这儿,希望我们推荐的文章对大家有所帮助,也希望大家多多支持为之网!


扫一扫关注最新编程教程