后端程序编码规范

JerryXia 发表于 May 22, 2013 , 阅读 (5,561)

这既是一个开发规范，本规范不是一成不变的必须严格遵守的条文，特殊情况下要灵活运用，可以做一定程度的变通。但是，请大家在实际开发过程中尽量遵守本规范，以利于协作。同时该规范还会指导Code Review，和设计评审等行为。

【命名规范】

1.1、命名总规则

所有名称的字符范围为：A-Z, a-z, 0-9 和_(下划线)。不建议使用其他字符作为名称。
采用英文单词或英文短语（包括缩写）作为名称，不使用无意义的字符或汉语拼音。
名称应该清晰明了，能够准确表达事物的含义，最好可读，遵循“见名知意”的原则。
提倡英文命名，切忌英文和拼音混用。

1.2、类库Namespace命名

类库分成三个层次，分别是.Net框架、公司基础公共类库、项目级类库。公共类库参照已有类库引用，以下主要对项目级Namespace命名提出参考建议：

YesHJ.Ucenter 用户中心
YesHJ.Cms 网站内容系统
YesHJ.Class 网校
YesHJ.Bulo 社区
YesHJ.Shop 网店
命名空间建议： YesHJ.{ProductLine}.{Appname}.XXXX =>例如：YesHJ.Bulo.KaoDian.XXXX

1.3、变量、方法命名

私有变量及方法参数使用camel命名（第一个词首字母用小写，其它词首字母用大写）
公共变量、方法、类使用Pascal命名（单词的首字母用大写）
公有变量尽量使用Property ，慎用Public Static变量；
变量命名要有意义：拒绝无意义的变量a，a1，b，k等；
典型的增删改查方法命名如下：比如获取GetUserList
用名词或名词短语命名属性；

1.4、文件、文件夹命名

目录命名建议和Class命名要求一致，不要出现“_”和“小写”开头，已经用小写的不需要调整，保证命名空间的命名符合标准即可。
特殊或者系统文件夹可保持大写方式，比如App_Code、App_WebReferences等；
文件命名一般采用小写，应用加下划线方式命名。
页面的命名和Class命名要求一致，注意不要小写开头。

【Web服务】

1.URL命名：

老的Api方式：app.hujiang.com.hjdns.net => {appName}.hjapi.hujiang.com (内部域名解析) 还有一些是使用 {appName}.yeshj.com

2.传参：不要暴露参数类型和参数值

不好的例子：
http://bulo.hujiang.com/service/GetUserFace.ashx?ver=2013%E5%B9%B44%E6%9C%8816%E6%97%A5%20 %E4%B8%8B%E5%8D%885:07:52&userId=12644342&callback=jQuery17207177500906400383_136610325 2485&_=1366103272413

应该是：
http://bulo.hujiang.com/service/GetUserFace.ashx?token=asdfkjsldjwlejfsldjflsdjlf&callback=jQuery17207177500906400383_1366103252485&_=1366103272413

3.类型和应用场景：

Web Service：传统用法，不宜调用太频繁。注意要有异常保护，即使不返回结果，也不要影响页面的其他功能，尽量用异步。
Rest Service：一般参数要保护；同样不宜调用太频繁。尽量用Json做数据格式。
WCF Service：适用于高安全、频繁调用，同时不能直接产生数据库关联的场景。

【代码风格】

2.1、代码前置后置

代码前后端分离：(code-behind)
好处，逻辑比较清晰，容易进行重构。
缺点：发布、维护繁琐一些。

今后新项目必须采用代码后置(code-behind)，不要再使用单页面（single-page code ），特别是UserControl等需要复用的，自己在维护代码时，修改单页面程序时，要把它改成code-behind。

建议：

需要简化前台代码的数量和复杂度，必要时需要分离出独立的Service层，前端的C#代码仅仅用来做交互性的操作，不要包含太多复杂逻辑。
新项目尽量采用Web Application Project，不建议使用Web Site Project。

2.2、注释

逻辑理解注释，采用//加注释语句
写在注释语句之前一行或者紧跟着注释语句后同一行
public,protect函数或者属性注释采用/// VS自动添加注释模式，
所有共有变量和共有方法都需要注释，类库中的protect和public的类要加类头注释

2.3、书写格式

在程序代码间一般不要连续留空两行
如果一个函数的参数很多，要么一行全部输入，要么一行一个参数
不要用空格缩进，统一用制表符缩进
对于一些比较长的块，使用#region 和#endregion 来括起来
单行代码要 < 80个字符
C#代码中的SQL要排版，方便阅读和维护；格式：参照数据库开发规范。

【程序开发安全与性能策略】

参数检查常见的像字符串参数，一般调用 String.IsNullOrEmpty函数来检查，或按照需要自己编写函数检查。对于数字、电话号码、身份证号等检查采用公用类库方法进行服务器端检查。对实体对象的ToString操作，一定要先做非空判断，或者调用Convert.ToString方法；
Sql注入防范对外部传入参数进行合法性检查，比如传址、表单、cookies数据；写数据库相关服务时，非特殊情况，必须使用参数化方式传递变量参数；敏感表用存储过程操作，限制连接sql权限，只赋予Select以及存储过程执行权限更新数据；
对于数据库连接的策略是尽早释放，如SqlDataReader用完之后一般采用Using自动释放连接，或者要主动调用Close方法关闭连接。
对于连续的ID，要防范恶意用户做推测性的攻击行为：可以使用Framework里面的FakeIDHelper、GuardIDHelper类进行伪装。
日志：
- 比较大的项目，我们需要选用Log4NET这样的比较成熟的日志组件。小一些的项目也可以使用.NET内置的System.Diagnostics里面的日志方法。
- 除了要建立ErrorLog日志之外，建议对每个后台服务的执行情况和执行时间做必要的监控：可以写Log文件、数据库、远程日志服务等，但是要考虑尽量减少对性能的影响，增加可维护性。特别是首次上线后，要通过监控，密切观察系统的运行情况，了解系统的性能瓶颈、产生原因等，方便对系统进行持续性优化。

【高级应用】

1.1 缓存策略

分布式缓存和.NET缓存测使用场景：

.NET Cache:要求更快，访问频繁，数据量较大的用.NET Cache；
Memcached:有一致性要求（多台Web server），数据量较小，读写不是特别频繁的用Memcached；大并发访问需要加锁，注意加锁方式。用检查Memcached的Key是否存在是锁不住的。
Redis:有一致性要求，数据量中等规模，读写比较频繁的可以考虑用Redis；

1.2 数据访问层的选择：

网站或应用的访问量大小、访问特点：逻辑是否复杂，实时性要求如何？
数据源的情况：是NoSQL还是关系数据库
ORM的选择：提倡选用轻量级的ORM框架：FlunetData http://fluentdata.codeplex.com/ 除非有特殊要求，今后大访问量的应用一般不要使用NHibernat和EntityFramework等比较重的ORM技术。

1.4 AOP：

推荐使用Postsharp，效率比较高。

【运维和部署】

Web Server的部署环境：

Windows 2003 64位+ II 6 +.NET 3.5
Windows 2008 R2 64位+ II 7 +.NET 4.0 or 4.5

[ C# ]