项目质量保证-编码规范

《项目质量保证-编码规范》由会员上传分享，免费在线阅读，更多相关内容在工程资料-天天文库。

1、软件项目质量保证一编码规范目录1编码规范的作用21.1提髙可都性21.2统一全局，促进团队协作21.3有助于知识传递，加快工作交接21.4减少名字增生，减低维护成本21.5强调变量之间的关系，降低缺陷引人的机会31.6提髙程序员的个人能力32编码规范不是神物33编写编码规范的一些建议33.1求同存异33.2定义编码规范越早越好43.3将规范分为强制部分和推荐部分43.4编码规范不要太长44编码规范参考44.1命名空间54.2代码风格54.3命名规范54.3.1类、结构、接口的命名54.3.2成员的命名64.3.3参数的命名74.3.4常量、变量的命

2、名74.3.5枚举的命名74.3.6资源的命名74.3.7数据库命名74.3.8XML命名84.4注释84.5异常处理81编码规范的作用作为软件开发者，我们可以开发低等级的软件，但不能开发低质量的软件。所以，如何实施质量保证，是我们关注的主要问题之一，而编码规范则是实施质量保证的第一步。编码规范已经成为一个老生常谈的问题，儿乎每个项目，每家公司都会定义自己的编码规范。但在真正实施时，却在有意或无意地违背编码规范。程序员，不喜欢改变自己的编程习惯。加之，管理者对质量控制不足，导致编码规范往往形同虚设。有些人会认为：遵守编码规范不能给项冃带来利益，也不

3、能让客户看到我们为此付出的努力，其完全是团队自发的行为，没有必耍做硬性的耍求。还有些人有更好的理由：编码规范会破坏创造性和程序质量。我认为，编码规范，在软件构件以及项目管理中，甚至是个人成长方面，都发挥着重要的作用，好的编码规范是提高我们代码质量的最有效的工具之一。1.1提高可读性“任何一个傻瓜都能写出计算机可以理解的代码，唯有写出人类容易理解的代码，才是优先的程序员。”编码规范，帮助我们写出人类容易理解的代码，它为我们提供了最基本的模板，良好的编码风格，使代码具有一定的描述性，可以通过名字来获取一些需要IDE才能得到的提示，如可访问性、继承基类等

4、。1-2统一全局，促进团队协作开发软件是一个团队活动，而不是个人的英雄主义。编码规范，要求团队成员遵守这一统一的全局决策，这样成员Z间可以轻松地阅读对方的代码，所有成员正以一种清晰而一致的风格进行编码。而且，开发人员也可以集中精力关注他们真正应该关注的问题一一自身代码的业务逻辑，与需求的契合度等局部问题。1.3有助于知识传递，加快工作交接风格的相似性，能让开发人员更迅速，更容易理解一些陌生的代码，更快速地理解别人的代码。因为，他和你的代码风格是一样的，你没有必要对他的一些个性化风格进行揣测。这样的好处是开发人员可以很快的接手项目组其他成员的工作，快

5、速完成工作交接。减少名字增生，减低维护成本在没有规范的情况下，和容易为同一类型的实例起不同的名字。对于以后维护这些代码程序员来说会产牛疑惑。1.5强调变量之间的关系，降低缺陷引人的机会命名可以表示一定的逻辑关系，是开发人员在使用时保持警惕，从而一定程度上减少缺陷被引人的机会。1.6提高程序员的个人能力不可否认，每个程序员都应该养成良好的编码习惯，而编码规范无疑是教材Z—。从一个程序员的代码本身能看出很多东西。所以，即便是为了自身发展，作为程序员也没有理由抵制这种规则的存在。你可能没有认识到，我们止默默地得益于编码规范。2编码规范不是“物神”在高质量

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

7、“物神”。编码规范仅仅是一个全局性质的规范，它只不过是一种编程约定，不能解决更深层次的问题。就像一篇格式漂亮但内容糟糕的论文不能被发表一样，你不能仅靠一个规范来摆脱软件作坊。而且，在编码规范中不宜包含那些冗长的开发技巧。我认为，对于代码是最佳实践应该是代码审查所要解决的，应该避免将编码规范写成一部关于重构的教科书。3编写编码规范的一些建议3.1求同存异不要妄图改变组织的编码习惯，除非有绝对合理的理由，否则还是以民主为主，毕竟你没有权利要求所有人都沿用你的编码习惯。3.2定义编码规范越早越好也早使用编码规范，也早享受其带来的好处。3.3将规范分为强制

8、部分和推荐部分求同存异的具体实现。将最基本的规范列放在强制部分，所有成员必须遵守;将好的但不重要的习惯列在推荐部分，开发人