项目质量保证-编码规范.docVIP

软件项目质量保证—编码规范 目录 1 编码规范的作用 1 1.1 提高可都性 2 1.2 统一全局，促进团队协作 2 1.3 有助于知识传递，加快工作交接 2 1.4 减少名字增生，减低维护成本 2 1.5 强调变量之间的关系，降低缺陷引人的机会 2 1.6 提高程序员的个人能力 2 2 编码规范不是神物 3 3 编写编码规范的一些建议 3 3.1 求同存异 3 3.2 定义编码规范越早越好 3 3.3 将规范分为强制部分和推荐部分 3 3.4 编码规范不要太长 3 4 编码规范参考 4 4.1 命名空间 4 4.2 代码风格 4 4.3 命名规范 4 4.3.1 类、结构、接口的命名 4 4.3.2 成员的命名 5 4.3.3 参数的命名 6 4.3.4 常量、变量的命名 6 4.3.5 枚举的命名 6 4.3.6 资源的命名 6 4.3.7 数据库命名 6 4.3.8 XML命名 7 4.4 注释 7 4.5 异常处理 7 编码规范的作用 作为软件开发者，我们可以开发低等级的软件，但不能开发低质量的软件。所以，如何实施质量保证，是我们关注的主要问题之一，而编码规范则是实施质量保证的第一步。 编码规范已经成为一个老生常谈的问题，几乎每个项目，每家公司都会定义自己的编码规范。但在真正实施时，却在有意或无意地违背编码规范。程序员，不喜欢改变自己的编程习惯。加之，管理者对质量控制不足，导致编码规范往往形同虚设。有些人会认为：遵守编码规范不能给项目带来利益，也不能让客户看到我们为此付出的努力，其完全是团队自发的行为，没有必要做硬性的要求。还有些人有更好的理由：编码规范会破坏创造性和程序质量。我认为，编码规范，在软件构件以及项目管理中，甚至是个人成长方面，都发挥着重要的作用，好的编码规范是提高我们代码质量的最有效的工具之一。 提高可读性 “任何一个傻瓜都能写出计算机可以理解的代码，唯有写出人类容易理解的代码，才是优先的程序员。”编码规范，帮助我们写出人类容易理解的代码，它为我们提供了最基本的模板，良好的编码风格，使代码具有一定的描述性，可以通过名字来获取一些需要IDE才能得到的提示，如可访问性、继承基类等。 统一全局，促进团队协作 开发软件是一个团队活动，而不是个人的英雄主义。编码规范，要求团队成员遵守这一统一的全局决策，这样成员之间可以轻松地阅读对方的代码，所有成员正以一种清晰而一致的风格进行编码。而且，开发人员也可以集中精力关注他们真正应该关注的问题——自身代码的业务逻辑，与需求的契合度等局部问题。 有助于知识传递，加快工作交接 风格的相似性，能让开发人员更迅速，更容易理解一些陌生的代码，更快速地理解别人的代码。因为，他和你的代码风格是一样的，你没有必要对他的一些个性化风格进行揣测。这样的好处是开发人员可以很快的接手项目组其他成员的工作，快速完成工作交接。 减少名字增生，减低维护成本 在没有规范的情况下，和容易为同一类型的实例起不同的名字。对于以后维护这些代码程序员来说会产生疑惑。 强调变量之间的关系，降低缺陷引人的机会 命名可以表示一定的逻辑关系，是开发人员在使用时保持警惕，从而一定程度上减少缺陷被引人的机会。 提高程序员的个人能力 不可否认，每个程序员都应该养成良好的编码习惯，而编码规范无疑是教材之一。从一个程序员的代码本身能看出很多东西。所以，即便是为了自身发展，作为程序员也没有理由抵制这种规则的存在。你可能没有认识到，我们正默默地得益于编码规范。 编码规范不是“物神” 在高质量的软件中，你可以看到“架构的概念完整性”与“底层实现”之间的关系。“实现”与“架构”必须是清晰一致的，这种内在的、固有的一致性，需要编码规范来维系。如果没有这种统一的约定，那么我们做出的东西可能会充斥着各种不同的风格，显得混乱且难以理解。团队成员之间可能很不理解彼此之间的想法，甚至是相互抨击。各种编码风格上的差异会不断扩大，而代码质量则不断下降。而且，团队成员会花费时间在理解不同编程风格之间的差异，而没有专注于真正应该解决的问题。这样的时间消耗是难以接受的。所以，在每一个高质量代码的背后，一定存在着一份优秀的编码规范。 然而，也必须认识到编码规范不是“物神”。编码规范仅仅是一个全局性质的规范，它只不过是一种编程约定，不能解决更深层次的问题。就像一篇格式漂亮但内容糟糕的论文不能被发表一样，你不能仅靠一个规范来摆脱软件作坊。而且，在编码规范中不宜包含那些冗长的开发技巧。我认为，对于代码是最佳实践应该是代码审查所要解决的，应该避免将编码规范写成一部关于重构的教科书。 编写编码规范的一些建议 求同存异 不要妄图改变组织的编码习惯，除非有绝对合理的理由，否则还是以民主为主，毕竟你没有权利要求所有人都沿用你的编码习惯。 定义编码规范越早越好 也早使用编码规范