软件项目质量保证:编码规范

作为软件开发者,我们可以开发低等级的软件,但不能开发低质量的软件。所以,如何实施质量保证,是我们关注的主要问题之一,而编码规范则是实施质量保证的第一步。

编码规范已经成为一个老生常谈的问题,几乎每个项目,每家公司都会定义自己的编码规范。但在真正实施时,却在有意或无意地违背编码规范。程序员,不喜欢改变自己的编程习惯。加之,管理者对质量控制不足,导致编码规范往往形同虚设。有些人会认为:遵守编码规范不能给项目带来利益,也不能让客户看到我们为此付出的努力,其完全是团队自发的行为,没有必要做硬性的要求。还有些人有更好的理由:编码规范会破坏创造性和程序质量。我认为,编码规范,在软件构件以及项目管理中,甚至是个人成长方面,都发挥着重要的作用,好的编码规范是提高我们代码质量的最有效的工具之一。

一、编码规范的作用

  • 提高可读性 “任何一个傻瓜都能写出计算机可以理解的代码,唯有写出人类容易理解的代码,才是优先的程序员。”编码规范,帮助我们写出人类容易理解的代码,它为我们提供了最基本的模板,良好的编码风格,使代码具有一定的描述性,可以通过名字来获取一些需要IDE才能得到的提示,如可访问性、继承基类等。
  • 统一全局,促进团队协作 开发软件是一个团队活动,而不是个人的英雄主义。编码规范,要求团队成员遵守这一统一的全局决策,这样成员之间可以轻松地阅读对方的代码,所有成员正以一种清晰而一致的风格进行编码。而且,开发人员也可以集中精力关注他们真正应该关注的问题——自身代码的业务逻辑,与需求的契合度等局部问题。
  • 有助于知识传递,加快工作交接 风格的相似性,能让开发人员更迅速,更容易理解一些陌生的代码,更快速地理解别人的代码。因为,他和你的代码风格是一样的,你没有必要对他的一些个性化风格进行揣测。这样的好处是开发人员可以很快的接手项目组其他成员的工作,快速完成工作交接。
  • 减少名字增生,降低维护成本 在没有规范的情况下,和容易为同一类型的实例起不同的名字。对于以后维护这些代码程序员来说会产生疑惑。
  • 强调变量之间的关系,降低缺陷引人的机会 命名可以表示一定的逻辑关系,是开发人员在使用时保持警惕,从而一定程度上减少缺陷被引人的机会。
  • 提高程序员的个人能力 不可否认,每个程序员都应该养成良好的编码习惯,而编码规范无疑是教材之一。从一个程序员的代码本身能看出很多东西。所以,即便是为了自身发展,作为程序员也没有理由抵制这种规则的存在。你可能没有认识到,我们正默默地得益于编码规范。

二、编码规范不是“物神”

在高质量的软件中,你可以看到“架构的概念完整性”与“底层实现”之间的关系。“实现”与“架构”必须是清晰一致的,这种内在的、固有的一致性,需要编码规范来维系。如果没有这种统一的约定,那么我们做出的东西可能会充斥着各种不同的风格,显得混乱且难以理解。团队成员之间可能很不理解彼此之间的想法,甚至是相互抨击。各种编码风格上的差异会不断扩大,而代码质量则不断下降。而且,团队成员会花费时间在理解不同编程风格之间的差异,而没有专注于真正应该解决的问题。这样的时间消耗是难以接受的。所以,在每一个高质量代码的背后,一定存在着一份优秀的编码规范。

然而,也必须认识到编码规范不是“物神”。编码规范仅仅是一个全局性质的规范,它只不过是一种编程约定,不能解决更深层次的问题。就像一篇格式漂亮但内容糟糕的论文不能被发表一样,你不能仅靠一个规范来摆脱软件作坊。而且,在编码规范中不宜包含那些冗长的开发技巧。我认为,对于代码是最佳实践应该是代码审查所要解决的,应该避免将编码规范写成一部关于重构的教科书。

三、编写编码规范的一些建议

以下是我对定义编码规范的一些建议:

  • 求同存异 不要妄图改变组织的编码习惯,除非有绝对合理的理由,否则还是以民主为主,毕竟你没有权利要求所有人都沿用你的编码习惯。
  • 定义编码规范越早越好 也早使用编码规范,也早享受其带来的好处。
  • 将规范分为强制部分和推荐部分 求同存异的具体实现。将最基本的规范列放在强制部分,所有成员必须遵守;将好的但不重要的习惯列在推荐部分,开发人员可以根据自己习惯选择是否使用。
  • 编码规范不要太长 太长的文档没人看,所有人都一样,除了礼品单和工资单没人愿意看长的东西,所以编码规范必须精炼,最好是只有2~3页,让开发人员可以打印出来随时查看。
  • 必须是约定俗成的 规范必须是行业中约定俗成的,不要有什么个性化发挥。

四、编码规范参考

我本人不太推荐制定过细的编码规范。制定编码规范是为了增强代码的可读性,毕竟代码的结构才是主要关注问题,所以我的编码规范还是比较简短的。里面只是对可能会破坏编码风格的行为进行约束,而没有细化到“空行”甚至“空格”的级别。

编码规范

一 命名空间

<公司名称>.(<产品名称>|<相关技术>)[.<用途>] [.<子命名空间>]

二 代码风格

  • 花括号“{}”不允许省略,即使只有一段代码。
  • 不允许省略访问修饰符。
  • 类型默认是密封的。
  • 不允许公开字段。
  • 使用括号“()”来强调运算符优先级。

三 命名规范

(一) 类、结构和接口的命名

  • 使用名词或名词短语。
  • 使用Pascal方式。
  • 在接口名称前加上前缀“I”。
  • 考虑在派生类末尾使用基类的名字。
  • 如果该类仅仅为了实现某个接口,那么请保持其与接口命名的统一。
  • 如果从.NET 框架中存在的类型派生的类型,应该遵循以下规范:
 基类  派生类
 System.Attribute  要给自定义的特性添加“Attribute”后缀
 System.Delegate  要给用于事件处理的委托添加“EventHandler”后缀

要给用于事件处理之外的那些委托添加“Callback”后缀

不要给委托添加“Delegate”后缀

 System.EventArgs  要添加“EventArgs”后缀
 System.Exception  要添加“Exception”后缀
 IDictionary,IDictionary<T,V>  要添加“Dictionary”后缀
 IEnumerable,ICollection,IList,

IEnumerable,ICollection,IList

 添加“Collection”后缀
 System.IO.Stream  添加“Stream”后缀
 CodeAccessPermission,IPermission  添加“Permission”后缀

(二) 成员的命名

 成员  大小写  规范
 方法  Pascal(公开)、Camel(私有)  用动词或动词短语命名
 属性  Pascal  用名词、名词短语或形容词来命名

集合属性应该使用复数形式,而不是添加后缀

用“Is”、“Can”、“Has”等表示布尔属性

可以用属性的类型名来命名属性

 事件  Pascal  使用动词或动词短语来命名事件

用现在时和过去时来区分前置和后置事件

 字段  Camel(私有)  要用名词、名词短语或形容词来命名

不要加任何前缀

(三) 参数的命名

  • Camel风格。
  • 要使用left和right来命名重载的二元操作符的参数——如果参数没有具体的含义。
  • 要使用value来命名重载的一元操作符的参数——如果参数没有具体的含义。
  • 不要在参数中使用数字编号。
  • 尽量使用描述性的名字命名泛型类型参数,并在前面使用“T”前缀。

(四) 常量、变量的命名

  • 常量——所有单词大写并用“_”分隔。
  • 局部变量——Camel风格。

(五) 枚举的命名

  • Pascal风格。
  • 使用名词的复数形式来命名标记枚举。
  • 不要添加“Enum”或“Flag”后缀。
  • 不要给枚举类型值的名字加前缀。

(六) 资源的命名

  • Pascal风格。
  • 仅使用字母、数字和下划线。
  • 在命名异常消息的资源时,资源标识符应该是异常类型名加上简短的异常标识符。

(七) 数据库命名

  • 表——“模块名_表名”。
  • 字段——bool类型用“Is”、“Can”、“Has”等表示;日期类型命名必须包含“Date”;时间类型必须包含“Time”。
  • 存储过程——使用“proc_”前缀。
  • 视图——使用“view_”前缀。
  • 触发器——使用“trig_”前缀。

(八) XML命名

节点名称使用Pascal风格,属性名称使用Camel风格。

四 注释

  • 对接口和复杂代码块必须进行注释。
  • 修改代码时保持注释同步。
  • 未完成的功能使用TODO标记。
  • 修改他人代码时要先注释对方代码,并写明修改原因,不允许随便删除他人代码。
  • 发布前移除无用注释。

五 异常处理

  • 原则上只允许显示抛出InvalidOperationException、ArgumentException、ArgumentNullException和ArgumentOutOfRangeException四种异常类型。
  • 在自定义异常时,必须使用VS提供的代码模板来创建自定义异常。
2 5 收藏 1 评论

相关文章

可能感兴趣的话题



直接登录
最新评论
跳到底部
返回顶部