当前位置:文档之家› 敏捷开发中编写高质量Java代码

敏捷开发中编写高质量Java代码

敏捷开发中编写高质量Java代码
敏捷开发中编写高质量Java代码

敏捷开发中编写高质量Java代码

敏捷开发的理念已经流行了很长的时间,在敏捷开发中的开发迭代阶段中,我们可以通过五个步骤,来有效的提高整个项目的代码质量。

Java项目开发过程中,由于开发人员的经验、Java代码编写习惯,以及缺乏统一的标准和管理流程,往往导致整个项目的代码质量较差,难于维护,需要较大的测试投入和周期等问题。这些问题在一个项目组初建、需求和设计均具有不完全可预期性和完备性的全新项目中将尤为突出。

如图1所示,敏捷开发过程经历需求调研,用例分析和用例分解,进入开发迭代阶段。在每个迭代过程中,可以采用以下步骤来保证和提高整个项目的代码质量:统一编码规范、代码样式;静态代码分析(staticcodereview);单元测试;持续集成;代码评审和重构(Review&Refactor)。下文将针对每个步骤和其所使用的工具、方法进行详细描述。

图1.敏捷开发中的Java代码质量保证步骤

步骤一:统一编码规范、代码样式

规范统一的编码会增加项目代码的可读性和可维护性,但实际情况往往是项目组内的Java代码开发人员的编码风格常常各不相同,这可能是由于不同的经验习惯或者缺乏编码规范方面的学习造成的。这样一来,其他项目成员或者维护人员在阅读项目代码时就需要花费

更多的时间来理解代码作者的意图,所以制定并采取统一的编码规范就显得很重要。编码规范主要应包含以下几个方面:

◆一般规则和格式规范。例如代码缩进、程序块规范、每行最大代码长度等。

◆命名规则。例如包名、类名、变量、方法、接口、参数等命名规范

◆文档规范。例如类文件头声明、类注释、成员变量和方法注释等规范。

◆编程规范。例如异常、并发、多线程等方面的处理方式。

◆其他规范。例如日志格式、属性文件格式,返回值和消息格式。

项目的编码规范可以参考已有的一些Java编程规范书籍和其他相关资料并结合项目的本身来制定,可供参考的书籍有《Java编程风格》(英文书名为:TheElementsofJavaStyle)。编码规范要形成文档,而且要简洁明了,并组织项目成员一起学习,确保所有成员正确理解所有条目。

一旦编码规范确定,就可以利用Eclipse自身提供的功能来控制代码样式和格式。具体做法是,点击Eclipse的Windows->Preference菜单项,在打开的Preferences对话框的左侧栏中找到Java节点下的子项CodeStyle(如图2),该项和它的子项允许您对Java代码的样式进行控制。

图2.Eclipse代码样式设置窗口

例如,为了使用自动格式化工具,可以在Eclipse提供的默认代码格式配置的基础上建立自定义的格式。在Formatter面板中,点击New,输入新的名字并选择一个默认的配置作为初始化格式,如图3所示。

图3.创建新的代码格式配置

单击OK后就可以在新打开的窗口中进行修改定制自己需要的格式。如图4所示。

图4.创建新的代码格式配置

修改完成后点击Apply保存所作修改。同时可以点击Export将当前的格式定义导出成一个XML文件,这样项目组的其他成员就可以很方便通过点击图3中的Import按钮来导入该XML文件来使用同一个代码格式定义。

这样每次在提交代码到版本控制服务器前就可以通过Eclipse界面里的Source->Format菜单来对代码进行格式化,从而使整个项目的代码具有相同的格式。同样可以通过对CodeStyle下的其他项目进行设置来帮助对Java代码的样式进行控制。将所有这些样式文件导出成XML文件后,同编码规范一起归档,供所有项目成员使用。

步骤二:静态代码分析

在完成源代码的开发以后,下面要进行的工作就是审视和测试代码。除了通过运行测试代码来检查功能之外,还能利用一些静态分析工具来快速、直接地提高代码质量。静态代码分析工具并不需要运行代码,可以直接对Java文件和Class文件进行分析,通过一些检查条件

的设置,快速找到代码中的错误和潜在缺陷。现在的静态分析工具很多,有FindBugs、PMD、IBMRationalTool,等等。在这里,选择FindBugs作为静态代码分析工具。FindBugs可以和日常开发工具Eclipse进行集成,在开发过程中,就可以方便的开始静态代码的检查。通过检查Class文件或者JAR文件,将字节码和一组缺陷模式进行对比,来发现可能存在的代码问题。在Eclipse的开发环境中,用插件安装的方式安装了Findbugs后,在Eclipse的配置选项中就会多出来FindBugs的配置选项。可以对自己的项目进行配置,选择需要的Detector检查代码。

图5.FindBugs的配置选项

设置好自己的规则后,在需要检查的代码文件夹上点击右键,就可以启动FindBugs检查。代码可以是一个项目,也可以只是几个文件。

图6.运行FindBugs

检查完毕后,会出现FindBugs视图,把所有检查的结果根据错误分组展示。点击结果里面的每一个错误,会自动打开对应的代码。当根据规则改正了所有的错误,或者说潜在错误,这些代码也就通过了静态代码检查。FindBugs的检查结果可以是XML文件,也可以是文本文件,便于项目的集成管理和检查保存。

图7.FindBugs检查结果

步骤三:单元测试

单元测试用例设计和评审

单元测试是软件开发过程中重要的质量保证环节,在此环节中,设计和评审对于保证整个单元测试过程的完整性和有效性来说十分重要。设计阶段需要具体考虑要对哪些代码单元进行测试,被测单元之间的关系,测试策略,以及单元测试用例设计等,并最终输出《单元测试用例设计》文档,用来指导具体的单元测试执行。在用例设计中,通过对代码单元输入和期待输出的定义来保证该单元的功能正确性,边界值的测试和异常测试非常重要。同时也配合测试用例和功能块的匹配方法来衡量用例设计的完整性。

在用例设计完成之后,下一步的工作就是进行测试用例的评审。个人的理解和经验始终是有限的,用例评审可以借集体之力,对用例设计进入查漏补缺,进一步保证测试用例的有效性。由于单元测试属于白盒测试范畴,它主要通过对代码的逻辑结构进行分析来设计测试用例,因此,评审员的选择最好以理解代码逻辑结构为前提,如果评审员来自相关模块,还能

够有效的发现模块相关性和依赖性所带来的问题。

模拟对象技术

在实际项目中,开发人员自己的代码往往需要和其他的代码模块或系统进行交互,但在测试的过程中,这些需要被调用的真实对象常常很难被实例化,或者这些对象在某些情况下无法被用来测试,例如,真实对象的行为无法预测,真实对象的行为难以触发,或者真实对象的运行速度很慢。这时候,就需要使用模拟对象技术(Mock),利用一个模拟对象来模拟我们的代码所依赖的真实对象,来帮助完成测试,提高测试覆盖率,从而提高代码质量。模拟对象技术利用了在面向接口的编程中,由于代码直接对接口进行调用,所以代码并不知道引用的是真实对象还是模拟对象,这样就可以顺利的完成对代码的测试,模拟技术有很多种,如jMock,EasyMock,Mockito,PowerMock等等。其中Mockito消除了对期望行为的需求,避免了这些代码的大量初始化。

图8.Mockito示例

在模拟对象过程中,先模拟一个需要调用的List对象LinkedList,再设定这个对象的行为,当调用get(0)的时候,返回”first”。这样,测试代码就可以利用这个对象来测试我们的功能代码,需要调用和返回值的时候,可以顺利的得到模拟对象的返回值。也需要对模拟对象进行错误情况的模拟,保证代码对错误的处理的正确性。

测试覆盖率分析

为了衡量单元测试的质量和覆盖的范围,需要对单元测试的代码进行测试覆盖分析。常用的衡量测试覆盖率的指标主要有语句覆盖率、分支覆盖率、路径覆盖率、条件覆盖率和方法覆盖率等。具体采用哪些指标可以根据项目的实际情况来定,以避免因过高的指标增加了代码开发人员的工作量而影响了项目整体的进度。

EMMA是一款比较流行的开源Java测试覆盖率分析工具,支持类、方法、代码行、基本代码块等多种类型的测试覆盖率分析,支持将覆盖率分析结果导出为多种格式的报告,并采

用多种颜色来高亮显示不同的覆盖率状态。EclEmma是一款基于EMMA的Eclipse插件,方便在EclipseIDE中进行测试覆盖率分析。如图9,在测试用例写好后,可以在右键点击测试类,选择CoverageAs->JUnitTest。

图9.运行测试覆盖分析

单元测试跑完后,Coverage视图中会显示所选择的测试的覆盖率。双击打开某一具体的类后,可以看到高亮显示的覆盖分析结果,如图10所示。红色代表测试没有覆盖到该行,黄色表示部分覆盖,绿色的行表示该行在本次测试中被覆盖到。

图10.查看测试覆盖分析结果

在Coverage视图中可以通过点击鼠标右键将测试覆盖分析的结果导出成需要的格式,例如HTML。

图11.导出测试覆盖分析结果

图12显示了导出的report。

图12.测试覆盖分析报告

为了保证单元测试的有效性和质量,可以规定一个测试覆盖率的下限,例如所有的包和类的覆盖率必须达到80%以上。不过值得注意的是,不要单纯追求高覆盖率,要同时注意测试用例的质量,如果测试用例本身就写的有错误,那么即使测试覆盖率很高也没有意义。

步骤四:持续集成

持续集成(ContinuousIntegration)是利用一系列的工具,方法和规则,做到快速的构建开发代码,自动的测试化,来提高开发代码的效率和质量。利用自动构建工具,随时都能把提交的代码构建出来,提供一个可以测试使用的版本,让用户和开发人员同时看到相同的功能,尽早的发现问题和错误,也可以尽快的得到测试人员和用户的反馈。

要做到持续集成,就要利用一系列工具,把开发过程中的重复工作自动化。搭建自动的构建服务器,自动的进行单元测试和发布新版本,一个集成的服务器可以提供构建过程的结果报告,自动通知开发人员构建结果,并且保存历史数据。IBMRationalTeamConcert(RTC)可以提供工作任务的管理,项目计划的安排,代码版本管理控制,自动构建可用版本,生成构建结果报告。这些过程构成了项目的持续集成过程,其中,版本的自动构建和代码的自动单元测试是持续集成的关键过程,RTC在这些过程上提供了有力的支持。

自动构建

RTC提供了buildengine来负责构建build,首选,启动buildengine,并和RTC服务器建立了连接。再创建项目的build定义。在这个定义中,需要设定编译哪些模块的代码,需要跳动哪个ANT文件来启动编译,和一些编译过程中的参数的设定。当这些都准备好了,编译对于项目而言,就变成一个简单的事情。

可以看到,通过在build定义上,点击请求构建,就可以触发一次构建过程。选择需要的构建参数,这个过程就会在后台运行。每一个开发人员,做了稍许的代码改变和提交,都可以触发新的构建过程,来保证我们代码的有效性。申请一个新的构建的过程如图13、图14所示。

图13.申请一个新的构建

图14.构建申请界面

当构建结束后。RTC服务器会提供构建结果报告。开发人员可以查询到这次构建的详细信息。

图15.构建结果

整个开发过程中,构建版本的过程应该是无数次的,通过每次构建,都可以得到当时代码的编译情况,并且可以得到一个可运行的软件版本。在构建定义上,RTC支持设置构建计划。定时自动的触发一次构建。

图16.构建定义

自动单元测试

构建可以自动了,重点提高代码质量的单元测试呢?如果每一天的代码,每一个版本的代码,都已经通过了我们的单元测试,这样我们就能对代码的质量有了基本的保证。在构建脚本的自动调用过程中,通过ANT的脚本,可以加上JUnit,EMMA,FindBugs的ANT脚本调用,每一次的构建,都可以把这些检查工作自动的进行一遍测试。这些测试都要生成测试结果报告,RTC不能提供这些报告的展示,就可以利用Hudson这个开源工具,集成测试报告来方便查阅。

图17.自动测试报告

步骤五:代码评审和重构

代码评审(CodeReview)是Java项目开发过程中的一个重要步骤,代码评审可以帮助发现静态代码分析过程中无法发现的一些问题,例如代码的编写是否符合编码规范,代码在逻辑上或者功能上是否存在错误,代码在执行效率和性能上是否有需要改进的地方,代码的注释是否完整正确,代码是否存在冗余和重复。代码评审还可以帮助新进入项目组的成员快速学习和了解项目,促进经验分享,同时也能保证项目成员的良好沟通。代码评审主要包括两种形式,同级评审(PeerReview)和小组评审(GroupReview)。同级评审主要指项目成员间的互相评审,小组评审是指通过召开评审会议,项目成员一起对项目代码进行评审。

为了提高代码评审的有效性和效率,可以借助一些外部工具,比较常用的代码评审工具有Jupiter和CodeStriker。Jupiter是一款开源的Eclipse插件,允许成员将评审意见定位到真实代码的具体行,由于代码评审的结果以XML文件的形式保存,所以可以把结果提交到版本管理服务器进行共享。图18显示了使用Jupiter进行代码评审的界面。

图18.Jupiter代码评审界面

在代码评审任务创建后,Jupiter将代码评审分成三个阶段,个人评审阶段(IndividualPhase)、团队评审阶段(TeamPhase)和问题修复阶段(ReworkPhase)。在个人评审阶段,评审成员将发现的代码问题或者缺陷记录下来,每个问题都会作为一个记录保存在评审表格中。在团队评审阶段,团队的全部或者部分成员会一起对个人评审阶段发现的问题进行定性,如果问题确实存在,就将该问题分配给某个成员去解决,并在Jupiter中将该问题设置成相应的状态。在问题修复阶段,团队成员会修复属于自己的问题,并将相应的记录设置成已解决等正确的状态。

Codestriker是一款基于Web的常用代码评审工具,对代码的评审可以针对某一具体行,也可以针对整个代码文件,评审意见会被保存在数据库中。评审人员可以同时看到其他人的评论,代码作者也可以针对某一具体的评论回复。Codestriker支持邮件通知,还可以同版本控制服务器进行集成,以跟踪和显示文件内容的改变。图19显示了Codestriker的界面。

图19.Codestriker报告界面

在实践中对所有代码进行小组评审会比较费时,所以可以根据实际情况来挑选一些核心代码进行小组评审,或者在项目的前期安排较多的小组评审,等项目组的成员对代码评审的标准和要求有较好的理解,进行代码评审的经验提高后,就可以逐渐减少小组评审的次数,从而达到大部分代码即使只进行同级评审也能保证很好的质量。

通过代码评审发现的问题要通过代码重构及时解决掉,较小的不涉及多人代码的重构可以由项目成员自己借助Eclipse的重构功能完成,不同项目成员写的实现相同功能的不同代码要通过讨论整合成公共的类或者方法。比较复杂的或者比较高层次的重构工作,例如整个项目层面的代码组织形式的改变需要由整个项目组共同讨论完成。

结论

软件开发没有一成不变、万能通用的流程和方法,希望大家能从本文得到启发和收益,结合您的实际项目特点,实践以上步骤和方法,并加以完善和改进,共同打造高效高质量的Java 代码,为您的项目成功奠定坚实的基础。

编写高质量代码--Web前端开发修炼之道笔记

第一章从网站重构说起 打造高质量的前端代码,提高代码的可维护性——精简、重用、有序。 第二章团队合作 精一行,通十行。 增加代码可读性——注释。 重用性需提高,分为公共组件与私有组件,代码模块化。公共组件不能轻易修改,因为影响大,所以一般只提供“读”的权限。 磨刀不误砍柴工——前期的构思很重要。构思的主要内容包括规范的制定、公共组件的设计和复杂功能的技术方案等。一般来说,前期构思占整个项目30%~60%的时间都算是正常的。 第三章高质量的HTML

CSS只是web标准的一部分,在HTML、CSS、JS三大元素中,HTML才是最重要的,结构才是重点,样式是用来修饰结构的。正确的做法是,先确定HTML,确定语义的标签,再来选用合适的CSS。 判断标签语义是否良好的简单方法:去掉样式,看网页结构是否组织良好有序,是否仍然有很好的可读性。语义良好的网页去掉样式后结构依然很清晰。 “CSS裸体日”,2006.04.05第一届,从第三届开始改为4月9日。(设立目的就是为了提醒大家用合适的HTML标签的重要性) 一个语义良好的页面,h标签应该是完整有序没有断层的,也就是说要按照h1、h2、h3、h4这样的次序排下来,不要出现类似h1、h3、h4,漏掉h2的情况。 当页面内标签无法满足设计需要时,才会适当添加div和span等五语义标签来辅助实现。 第四章高质量的CSS 组织CSS的方法:base.css+common.css+page.css,在一般情况下任何一个网页的最终表现都是由这三者共同完成的,这三者不是并列结构,而是层叠结构。

base.css一般包括cssreset和通用原子类,比如设置一些常用的清除浮动、宽度、高度等class。可以参考一些前端框架,例如YUI、bootstrap等等。 拆分模块技巧:模块与模块之间尽量不要包含相同的部分,如果有相同部分,应将它们提取出来,拆分成一个独立的模块。模块应在保证数量尽可能少的原则下,做到尽可能简单,以提高重用性。 团队开发人员多,可在classname前加前缀。 如果不确定模块的上下margin特别稳定,最好不要将它们写到模块的类里,而是使用类的组合,单独为上下margin挂用于边距的原子类(例如mt10、mb20)。模块最好不用混用margin-top和margin-bottom,统一使用margin-top或margin-bottom。 低权重原则——避免滥用子选择器 普通标签权重1,class权重10,id权重100 为了保证样式容易被覆盖,提高可维护性,CSS选择符需保证权重尽可能低。 CSS sprite的最大好处是减少HTTP请求数,减轻服务器的压力,但它却需要付出“降低开发效率”和“增大维护难度”的代价。对于流量并不大的网站来说,CSS sprite带来的好处并不明显,而它付出的代价却很大,其实并不划算。所以是否使用CSS sprite主要取决于网站流量。 编码风格:推荐一行书写,能减少文件大小。(因为调试工具多,所以忽略易读性)Hack: A标签问题:

敏捷开发中高质量Java代码开发实践

本文将介绍在敏捷开发过程中如何通过采取一系列的步骤来保证和提高整个项目的代码质量,阐述了每一步可以利用的工具和最佳实践,从而使开发过程更加规范化,成就高质量的代码。 概述 Java项目开发过程中,由于开发人员的经验、代码风格各不相同,以及缺乏统一的标准和管理流程,往往导致整个项目的代码质量较差,难于维护,需要较大的测试投入和周期等问题。这些问题在一个项目组初建、需求和设计均具有不完全可预期性和完备性的全新项目中将尤为突出。本文将结合敏捷开发周期短,变化快等特点,介绍如何通过在开发过程中采取一系列步骤来保证和提高整个开发团队的代码质量,并阐述了每一步可以利用的工具和最佳实践,从而使开发过程更加规范化,成就高质量的代码,减少测试的投入,并促进整个团队的技能提高,最终提高开发效率和质量。 如图1所示,敏捷开发过程经历需求调研,用例分析和用例分解,进入开发迭代阶段。在每个迭代过程中,可以采用以下五个步骤来保证和提高整个项目的代码质量:统一编码规范、代码样式;静态代码分析(static code review);单元测试;持续集成;代码评审和重构(Review&Refactor)。下文将针对每个步骤和其所使用的工具、方法进行详细描述。 图 1.敏捷开发中的Java代码质量保证步骤 步骤一:统一编码规范、代码样式 规范统一的编码会增加项目代码的可读性和可维护性,但实际情况往往是项目组内的Java代码开发

人员的编码风格常常各不相同,这可能是由于不同的经验习惯或者缺乏编码规范方面的学习造成的。这样一来,其他项目成员或者维护人员在阅读项目代码时就需要花费更多的时间来理解代码作者的意图,所以制定并采取统一的编码规范就显得很重要。编码规范主要应包含以下几个方面: ?一般规则和格式规范。例如代码缩进、程序块规范、每行最大代码长度等。 ?命名规则。例如包名、类名、变量、方法、接口、参数等命名规范 ?文档规范。例如类文件头声明、类注释、成员变量和方法注释等规范。 ?编程规范。例如异常、并发、多线程等方面的处理方式。 ?其他规范。例如日志格式、属性文件格式,返回值和消息格式。 项目的编码规范可以参考已有的一些Java编程规范书籍和其他相关资料并结合项目的本身来制定,可供参考的书籍有《Java编程风格》(英文书名为:The Elements of Java Style)。编码规范要形成文档,而且要简洁明了,并组织项目成员一起学习,确保所有成员正确理解所有条目。 一旦编码规范确定,就可以利用Eclipse自身提供的功能来控制代码样式和格式。具体做法是,点击Eclipse的Windows->Preference菜单项,在打开的Preferences对话框的左侧栏中找到Java节点下的子项Code Style(如图2),该项和它的子项允许您对Java代码的样式进行控制。 图 2.Eclipse代码样式设置窗口

编写高质量Java代码

敏捷开发中编写高质量Java代码 敏捷开发的理念已经流行了很长的时间,在敏捷开发中的开发迭代阶段中,我们可以通过五个步骤,来有效的提高整个项目的代码质量。 Java项目开发过程中,由于开发人员的经验、Java代码编写习惯,以及缺乏统一的标准和管理流程,往往导致整个项目的代码质量较差,难于维护,需要较大的测试投入和周期等问题。这些问题在一个项目组初建、需求和设计均具有不完全可预期性和完备性的全新项目中将尤为突出。 如图1所示,敏捷开发过程经历需求调研,用例分析和用例分解,进入开发迭代阶段。在每个迭代过程中,可以采用以下步骤来保证和提高整个项目的代码质量:统一编码规范、代码样式;静态代码分析(staticcodereview);单元测试;持续集成;代码评审和重构 (Revi ew&Refactor)。下文将针对每个步骤和其所使用的工具、方法进行详细描述。 图1.敏捷开发中的Java代码质量保证步骤 步骤一:统一编码规范、代码样式 规范统一的编码会增加项目代码的可读性和可维护性,但实际情况往往是项目组内的Java代码开发人员的编码风格常常各不相同,这可能是由于不同的经验习惯或者缺乏编码规范方面的学习造成的。这样一来,其他项目成员或者维护人员在阅读项目代码时就需要花费更多的时间来理解代码作者的意图,所以制定并采取统一的编码规范就显得很重要。编码规范主要应包含以下几个方面: ◆一般规则和格式规范。例如代码缩进、程序块规范、每行最大代码长度等。 ◆命名规则。例如包名、类名、变量、方法、接口、参数等命名规范 ◆文档规范。例如类文件头声明、类注释、成员变量和方法注释等规范。 ◆编程规范。例如异常、并发、多线程等方面的处理方式。 ◆其他规范。例如日志格式、属性文件格式,返回值和消息格式。

我编写过的最漂亮的代码

第3章我编写过的最漂亮的代码 Jon Bentley 我曾经听一位大师级的程序员这样称赞到,“我通过删除代码来实现功能的提升。”而法国著名作家兼飞行家Antoine de Saint-Exupéry的说法则更具代表性,“只有在不仅没有任何功能可以添加,而且也没有任何功能可以删除的情况下,设计师才能够认为自己的工作已臻完美。”某些时候,在软件中根本就不存在最漂亮的代码,最漂亮的函数,或者最漂亮的程序。 当然,我们很难对不存在的事物进行讨论。本章将对经典Quicksort(快速排序)算法的运行时间进行全面的分析,并试图通过这个分析来说明上述观点。在第一节中,我将首先根据我自己的观点来回顾一下Quicksort,并为后面的内容打下基础。第二节的内容将是本章的重点部分。我们将首先在程序中增加一个计数器,然后通过不断地修改,从而使程序的代码变得越来越短,但程序的功能却会变得越来越强,最终的结果是只需要几行代码就可以使算法的运行时间达到平均水平。在第三节将对前面的技术进行小结,并对二分搜索树的运行开销进行简单的分析。最后的两节将给出学完本章得到的一些启示,这将有助于你在今后写出更为优雅的程序。 3.1 我编写过的最漂亮代码 当Greg Wilson最初告诉我本书的编写计划时,我曾自问编写过的最漂亮的代码是什么。这个有趣的问题在我脑海里盘旋了大半天,然后我发现答案其实很简单:Quicksort算法。但遗憾的是,根据不同的表达方式,这个问题有着三种不同的答案。 当我撰写关于分治(divide-and-conquer)算法的论文时,我发现 C.A.R. Hoare的Quicksort算法(“Quicksort”,Computer Journal 5)无疑是各种Quicksort算法的鼻祖。这是一种解决基本问题的漂亮算法,可以用优雅的代码实现。我很喜欢这个算法,但我总是无法弄明白算法中最内层的循环。我曾经花两天的时间来调试一个使用了这个循环的复杂程序,并且几年以来,当我需要完成类似的任务时,我会很小心地复制这段代码。虽然这段代码能够解决我所遇到的问题,但我却并没有真正地理解它。 我后来从Nico Lomuto那里学到了一种优雅的划分(partitioning)模式,并且最终编写出了我能够理解,甚至能够证明的Quicksort算法。William Strunk Jr.针对英语所提出的“良好的写作风格即为简练”这条经验同样适用于代码的编写,因此我遵循了他的建议,“省略不必要的字词”(来自《The Elements of Style》一书)。我最终将大约40行左右的代码缩减为十几行的代码。因此,如果要回答“你曾编写过的最漂亮代码是什么?”这个问题,那么我的答案就是:在我编写的《Programming Pearls, Second Edition》(Addison-Wesley)一书中给出的Quichsort算法。在示例3-1中给出了用C语言编写的Quicksort函数。我们在接下来的章节中将进一步地研究和改善这个函数。 【示例】 3-1 Quicksort函数 void quicksort(int l, int u) { int i, m; if (l >= u) return;

敏捷开发中编写高质量Java代码+

敏捷开发中编写高质量Java代码收藏 敏捷开发的理念已经流行了很长的时间,在敏捷开发中的开发迭代阶段中,我们可以通过五个步骤,来有效的提高整个项目的代码质量。 Java项目开发过程中,由于开发人员的经验、Java代码编写习惯,以及缺乏统一的标准和管理流程,往往导致整个项目的代码质量较差,难于维护,需要较大的测试投入和周期等问题。这些问题在一个项目组初建、需求和设计均具有不完全可预期性和完备性的全新项目中将尤为突出。 如图1所示,敏捷开发过程经历需求调研,用例分析和用例分解,进入开发迭代阶段。在每个迭代过程中,可以采用以下步骤来保证和提高整个项目的代码质量:统一编码规范、代码样式;静态代码分析(staticcodereview);单元测试;持续集成;代码评审和重构(Review&Refact or)。下文将针对每个步骤和其所使用的工具、方法进行详细描述。 图1.敏捷开发中的Java代码质量保证步骤

步骤一:统一编码规范、代码样式 规范统一的编码会增加项目代码的可读性和可维护性,但实际情况往往是项目组内的Java代码开发人员的编码风格常常各不相同,这可能是由于不同的经验习惯或者缺乏编码规范方面的学习造成的。这样一来,其他项目成员或者维护人员在阅读项目代码时就需要花费更多的时间来理解代码作者的意图,所以制定并采取统一的编码规范就显得很重要。编码规范主要应包含以下几个方面: ◆一般规则和格式规范。例如代码缩进、程序块规范、每行最大代码长度等。 ◆命名规则。例如包名、类名、变量、方法、接口、参数等命名规范 ◆文档规范。例如类文件头声明、类注释、成员变量和方法注释等规范。 ◆编程规范。例如异常、并发、多线程等方面的处理方式。 ◆其他规范。例如日志格式、属性文件格式,返回值和消息格式。 项目的编码规范可以参考已有的一些Java编程规范书籍和其他相关资料并结合项目的本身来制定,可供参考的书籍有《Java编程风格》(英文书名为:TheElementsofJavaStyle)。编码规范要形成文档,而且要简洁明了,并组织项目成员一起学习,确保所有成员正确理解所有条目。 一旦编码规范确定,就可以利用Eclipse自身提供的功能来控制代码样式和格式。具体做法是,点击Eclipse的Windows->Preference菜单项,在打开的Preferences对话框的左侧栏中找到Java节点下的子项CodeStyle(如图2),该项和它的子项允许您对Java代码的样式进行控制。

编写高质量的代码,从命名入手

编写高质量的代码,从命名入手 笔者从事开发多年,有这样一种感觉,查看一些开源项目,如Spring、Apache Common等源码是一件赏心悦目的事情,究其原因,无外两点:1)代码质量非常高;2)命名特别规范(这可能跟老外的英语水平有关)。 要写高质量的代码,不是一件容易的事,需要长年累月的锻炼,是一个量变到质变的过程,但要写好命名,只需要有比较好的英语语法基础和一种自我意识即可轻松达到。本博文将会结合本人的开发经验,总结出若干命名规则,这些命名规则纯属个人的使用习惯,不代表是一种理想的规则,在这里列举出来,供大家交流讨论。 1.切忌使用没有任何意义的英语字母进行命名 for(int i=0; i<10; i++) { ... } 这是在很多教Java基本语法的书上常见的代码片断,作为教学材料,这样写无可厚非,但作为真正的代码编写,程序员必须要养成良好的习惯,不要使用这种没有任何含义的命名方式,这里可以使用“index”。 2.切忌使用拼音,甚至是拼音首字母组合 cishu =5; // 循环的次数 zzje = 1000.00// 转账金额 笔者在做代码检查的时候,无数次遇到过这样的命名,使人哭笑不得 3.要使用英文,而且要使用准确的英语,无论是拼写还是语法 名词单数,必须使用单数英文,如Account、Customer。 对于数组,列表等对象集合的命名,必须使用复数,而且最好按照英文的语法基础知识使用准确的复数形式,如List accounts、Set strategies。 对于boolean值的属性,很多开发人员习惯使用isXXX,如isClose(是否关闭),但这里有两点建议:1)最好不要带“is”,因为JavaBean的规范,为属性生成get/set方法的时候,会用“get/set/is”,上面的例子,生成get/set方法就会变成“getIsClose/isIsClose/getIsClose”,非常别扭;2)由于boolean值通常反映“是否”,所以准确的用法,应该是是用“形容词”,上面的例子,最终应该被改为closed,那么get/set方法就是“getClosed/isColsed/setClosed”,非常符合英语阅读习惯。 4.方法名的命名,需要使用“动宾结构短语”或“是动词+表语结构短语” 笔者曾看到过千奇百怪的方法命名,有些使用名词,有些甚至是“名词+动词”,而且,如果宾语是一个对象集合,还是最好使用复数: createOrder(Order order) //good orderCreate(Order order) //bad removeOrders(List orders) //good removeOrder(List order) //bad 5.对于常见的“增删改查”方法,命名最好要谨慎: 增加:最常见使用create和add,但最好根据英语的语义进行区分,这有助于理解,create 代表创建,add代表增加。比如,要创建一个Student,用createStudent要比用addStudent 好,为什么?想想如果有个类叫Clazz(班级,避开Java关键字),现在要把一个Student加入到一个Clazz,Clazz很容易就定义了一个addStudent(Student student)的方法,那么就比

如何提高代码质量

我们评价高质量代码有三要素:可读性、可维护性、可变更性。我们的代码要一个都不能少地达到了这三要素的要求才能算高质量的代码。 今天这堂培训课讲什么呢?我既不讲Spring,也不讲Hibernate,更不讲Ext,我不讲任何一个具体的技术。我们抛开任何具体的技术,来谈谈如何提高代码质量。如何提高代码质量,相信不仅是在座所有人苦恼的事情,也是所有软件项目苦恼的事情。如何提高代码质量呢,我认为我们首先要理解什么是高质量的代码。 高质量代码的三要素 我们评价高质量代码有三要素:可读性、可维护性、可变更性。我们的代码要一个都不能少地达到了这三要素的要求才能算高质量的代码。 1. 可读性强 一提到可读性似乎有一些老生常谈的味道,但令人沮丧的是,虽然大家一而再,再而三地强调可读性,但我们的代码在可读性方面依然做得非常糟糕。由于工作的需要,我常常需要去阅读他人的代码,维护他人设计的模块。每当我看到大段大段、密密麻麻的代码,而且还没有任何的注释时常常感慨不已,深深体会到了这项工作的重要。由于分工的需要,我们写的代码难免需要别人去阅读和维护的。而对于许多程序员来说,他们很少去阅读和维护别人的代码。正因为如此,他们很少关注代码的可读性,也对如何提高代码的可读性缺乏切身体会。有时即使为代码编写了注释,也常常是注释语言晦涩难懂形同天书,令阅读者反复斟酌依然不明其意。针对以上问题,我给大家以下建议: 1)不要编写大段的代码 如果你有阅读他人代码的经验,当你看到别人写的大段大段的代码,而且还不怎么带注释,你是怎样的感觉,是不是“嗡”地一声头大。各种各样的功能纠缠在一个方法中,各种变量来回调用,相信任何人多不会认为它是高质量的代码,但却频繁地出现在我们编写的程序了。如果现在你再回顾自己写过的代码,你会发现,稍微编写一个复杂的功能,几百行的代码就出去了。一些比较好的办法就是分段。将大段的代码经过整理,分为功能相对独立的一段又一段,并且在每段的前端编写一段注释。这样的编写,比前面那些杂乱无章的大段代码确实进步了不少,但它们在功能独立性、可复用性、可维护性方面依然不尽人意。从另一个比较专业的评价标准来说,它没有实现低耦合、高内聚。我给大家的建议是,将这些相对独立的段落另外封装成一个又一个的函数。

高质量编程指南

高质量C++/C 编程指南 文件标识: 当前版本: 1.0 作 者:林锐 博士 文件状态 [ ] 草稿文件 [√] 正式文件 [ ] 更改正式文件 完成日期: 2001年7月24日

版本历史 版本/状态作者参与者起止日期备注 V 0.9 草稿文件林锐 2001-7-1至 2001-7-18 林锐起草 V 1.0 正式文件林锐 2001-7-18至 2001-7-24 朱洪海审查V 0.9, 林锐修正草稿中的错误

目录 前言 (6) 第1章文件结构 (11) 1.1版权和版本的声明 (11) 1.2头文件的结构 (12) 1.3定义文件的结构 (13) 1.4头文件的作用 (13) 1.5目录结构 (14) 第2章程序的版式 (15) 2.1空行 (15) 2.2代码行 (16) 2.3代码行内的空格 (17) 2.4对齐 (18) 2.5长行拆分 (19) 2.6修饰符的位置 (19) 2.7注释 (20) 2.8类的版式 (21) 第3章命名规则 (22) 3.1共性规则 (22) 3.2简单的W INDOWS应用程序命名规则 (23) 3.3简单的U NIX应用程序命名规则 (25) 第4章表达式和基本语句 (26) 4.1运算符的优先级 (26) 4.2复合表达式 (27) 4.3 IF 语句 (27) 4.4循环语句的效率 (29) 4.5 FOR 语句的循环控制变量 (30) 4.6 SWITCH语句 (30) 4.7 GOTO语句 (31) 第5章常量 (33) 5.1为什么需要常量 (33) 5.2 CONST 与#DEFINE的比较 (33) 5.3常量定义规则 (33) 5.4类中的常量 (34) 第6章函数设计 (36)

高质量代码三要素

高质量代码的三要素 我们评价高质量代码有三要素:可读性、可维护性、可变更性。我们的代码要一个都不能少地达到了这三要素的要求才能算高质量的代码。 1.可读性强 一提到可读性似乎有一些老生常谈的味道,但令人沮丧的是,虽然大家一而再,再而三地强调可读性,但我们的代码在可读性方面依然做得比较糟糕。每当我看到大段大段、密密麻麻的代码,而且还没有任何的注释时常常感慨不已,深深体会到了这项工作的重要。由于分工的需要,我们写的代码难免需要别人去阅读和维护的。而对于许多程序员来说,他们很少去阅读和维护别人的代码。正因为如此,他们很少关注代码的可读性,也对如何提高代码的可读性缺乏切身体会。有时即使为代码编写了注释,也常常是注释语言晦涩难懂形同天书,令阅读者反复斟酌依然不明其意。针对以上问题,我给大家以下建议: 1)不要编写大段的代码 如果你有阅读他人代码的经验,当你看到别人写的大段大段的代码,而且还不怎么带注释,你是怎样的感觉,是不是“嗡”地一声头大。各种各样的功能纠缠在一个方法中,各种变量来回调用,相信任何人都不会认为它是高质量的代码,但却频繁地出现在我们编写的程序了。如果现在你再回顾自己写过的代码,你会发现,稍微编写一个复杂的功能,几百行的代码就出去了。一些比较好的办法就是分段。将大段的代码经过整理,分为功能相对独立的一段又一段,并且在每段的前端编写一段注释。这样的编写,比前面那些杂乱无章的大段代码确实进步了不少,但它们在功能独立性、可复用性、可维护性方面依然不尽人意。从另一个比较专业的评价标准来说,它没有实现低耦合、高内聚。我给大家的建议是,将这些相对独立的段落另外封装成一个又一个的函数。 许多大师在自己的经典书籍中,都鼓励我们在编写代码的过程中应当养成不断重构的习惯。我们在编写代码的过程中常常要编写一些复杂的功能,起初是写在一个类的一个函数中。随着功能的逐渐展开,我们开始对复杂功能进行归纳整理,整理出了一个又一个的独立功能。这些独立功能有它与其它功能相互交流的输入输出数据。当我们分析到此处时,我们会非常自然地要将这些功能从原函数中分离出来,形成一个又一个独立的函数,供原函数调用。在编写这些函数时,我们应当仔细思考一下,为它们取一个释义名称,并为它们编写注释(后面还将详细讨论这个问题)。另一个需要思考的问题是,这些函数应当放到什么地方。这些函数可能放在原类中,也可能放到其它相应职责的类中,其遵循的原则应当是“职责驱动设计”(后面也将详细描述)。 在编写代码的过程中,通常有两种不同的方式。一种是从下往上编写,也就是按照顺序,每分出去一个函数,都要将这个函数编写完,才回到主程序,继

良好的代码编写风格(二十五条)

[VHDL+Verilog]良好的代码编写风格(二十五条) 良好代码编写风格可以满足信、达、雅的要求。在满足功能和性能目标的前提下,增强代码的可读性、可移植性,首要的工作是在项目开发之前为整个设计团队建立一个命名约定和缩略语清单,以文档的形式记录下来,并要求每位设计人员在代码编写过程中都要严格遵守。良好代码编写风格的通则概括如下:(1)对所有的信号名、变量名和端口名都用小写,这样做是为了和业界的习惯保持一致;对常量名和用户定义的类型用大写; (2)使用有意义的信号名、端口名、函数名和参数名; (3)信号名长度不要太长; (4)对于时钟信号使用clk 作为信号名,如果设计中存在多个时钟,使用clk 作为时钟信号的前缀;(5)对来自同一驱动源的信号在不同的子模块中采用相同的名字,这要求在芯片总体设计时就定义好顶层子模块间连线的名字,端口和连接端口的信号尽可能采用相同的名字; (6)对于低电平有效的信号,应该以一个下划线跟一个小写字母b 或n 表示。注意在同一个设计中要使用同一个小写字母表示低电平有效; (7)对于复位信号使用rst 作为信号名,如果复位信号是低电平有效,建议使用rst_n; (8)当描述多比特总线时,使用一致的定义顺序,对于verilog 建议采用bus_signal[x:0]的表示; (9)尽量遵循业界已经习惯的一些约定。如*_r 表示寄存器输出,*_a 表示异步信号,*_pn 表示多周期路径第n 个周期使用的信号,*_nxt 表示锁存前的信号,*_z 表示三态信号等; (10)在源文件、批处理文件的开始应该包含一个文件头、文件头一般包含的内容如下例所示:文件名,作者,模块的实现功能概述和关键特性描述,文件创建和修改的记录,包括修改时间,修改的内容等;(11)使用适当的注释来解释所有的always 进程、函数、端口定义、信号含义、变量含义或信号组、变量组的意义等。注释应该放在它所注释的代码附近,要求简明扼要,只要足够说明设计意图即可,避免过于复杂; (12)每一行语句独立成行。尽管VHDL 和Verilog 都允许一行可以写多个语句,当时每个语句独立成行可以增加可读性和可维护性。同时保持每行小于或等于72 个字符,这样做都是为了提高代码得可读性;(13)建议采用缩进提高续行和嵌套语句得可读性。缩进一般采用两个空格,如西安交通大学SOC 设计中心2 如果空格太多则在深层嵌套时限制行长。同时缩进避免使用TAB 键,这样可以避免不同机器TAB 键得设置不同限制代码得可移植能力; (14)在RTL 源码的设计中任何元素包括端口、信号、变量、函数、任务、模块等的命名都不能取V erilog 和VHDL 语言的关键字; (15)在进行模块的端口申明时,每行只申明一个端口,并建议采用以下顺序: 输入信号的clk、rst、enables other control signals、data and address signals。然后再申明输出信号的clk、rst、enalbes other control signals、data signals; (16)在例化模块时,使用名字相关的显式映射而不要采用位置相关的映射,这样可以提高代码的可读性和方便debug 连线错误; (17)如果同一段代码需要重复多次,尽可能使用函数,如果有可能,可以将函数通用化,以使得它可以复用。注意,内部函数的定义一般要添加注释,这样可以提高代码的可读性; (18)尽可能使用循环语句和寄存器组来提高源代码的可读性,这样可以有效地减少代码行数; (19)对一些重要的always 语句块定义一个有意义的标号,这样有助于调试。注意标号名不要与信号名、

如何编写高质量的软件技术文档

如何编写高质量的软件文档 摘要: 本文首先阐述了软件文档的重要性;接着描述了软件文档的分类和编写原则、技巧;最后针对我们在编写概要设计说明书中存在的不足,提出了一些指导性原则和大家分享。通过这次分享,希望对大家编写概设等文档时有所帮助。 正文: 我在面试的时候,发现好多公司面试官都不问我写代码的能力如何,JAVA的熟练程度如何,而问我口头和书面表达能力如何,写方案的能力如何,他还说,你写的代码可能只有你的团队或将来维护你程序的人来看;而高层领导,老板和客户他们只看文档的,不会看你的代码的(不是说代码不重要,保证程序运行的正确性和提高代码的运行效率是程序员最基本的能力和职责),刚开始觉着很奇怪,可仔细想想,确实是那样,像我们这种写了多年代码的程序员来说,除了写好代码,其实写得一手好文档尤其重要,文档写不好是程序员向上发展的瓶颈,要提升自己可以先从编写高质量的文档开始。 对于软件开发人员来说,除了保证程序运行的正确性和提高代码的运行效率之外,规范化的文档编制将会对软件的升级、修改、

维护带来极大的方便。因此,开发一个高质量的软件产品,除了完成软件程序本身编制外,还必须提供完整详细的软件文档。 在软件生命周期中,软件文档记载了所有与软件有关的需求、开发、方法等核心技术信息,是保证软件项目开发、运行、维护和管理的重要技术资料。 为了何证软件开发、维护等环节的有效管理以及方便软件技术人员之间进行技术交流,在软件生命周期的每一阶段,都需要编制不同内容的文档。这些文档连同计算机程序及数据一起,构成计算机软件。 软件文档也称做软件文件,是一种重要的软件工程技术资源,例如技术文档、设计文档。软件文档和计算机程序共同构成了能完成特定功能的计算机软件,因此可以说没有文档的软件,不能称其为软件,更不能成为软件产品。 软件文档的规范编制在软件开发工作中占有突出的地位和相当的工作量。高质量地编制、分发、管理和维护文档,及时地变更、修正、扩充和使用文档,对于充分发挥软件产品的效益有着十分重要的意义。 一、软件文档的重要性 软件文档作为计算机软件的重要组成部分,在软件开发人员、软件管理人员、软件维护人员、用户以及计算机之间起着重要的桥梁作用,软件开发人员通过软件文档交流设计思想和设计软件;软件管理人员通过文档了解软件开发项目安

C#代码--编写高质量C#程序

1.1 换行的讲究 (6) 1.1.1 寻找最佳的断行位置 (6) 1.1.2 每行只写一条语句 (8) 1.1.3 分行定义变量 (9) 1.2 避免代码过于拥挤 (10) 1.2.1 使用空行分隔代码块 (10) 1.2.2 使用空格降低代码密度 (14) 1.3 如何缩进 (16) 1.3.1 嵌套或包含关系引起的缩进 (18) 1.3.2 因换行而产生的缩进 (22) 1.3.3 使用空格还是Tab键 (23) 1.4 大括号 (23) 1.4.1 大括号的位置 (23) 1.4.2 空的大括号结构 (24) 1.4.3 仅包含单个语句的结构体 (28) 1.5 保持项目文件的条理性 (30) 1.5.1 解决方案的结构呼应 (30) 1.5.2 代码文件的结构 (31) 1.5.3 使用#region标记 (34) 第2章养成良好的注释习惯 (34) 2.1 何时需要注释 (35) 2.1.1 解释代码的意图 (35) 2.1.2 对局部变量的说明 (36) 2.1.3 充当代码标题 (37) 2.1.4 指出例外情况 (41)

2.1.5 开发提示 (41) 2.2 注释的格式 (42) 2.2.1 单行注释 (43) 2.2.2 多行注释 (44) 2.3 正确使用XML文档注释 (45) 2.3.1 结构与类的XML文档注释 (46) 2.3.2 属性的XML文档注释 (47) 2.3.3 方法的XML文档注释 (49) 2.3.4 构造函数的XML文档注释 (50) 2.3.5 事件的XML文档注释 (51) 2.3.6 枚举类型的XML文档注释 (53) 2.3.7 泛型的XML文档注释 (53) 2.3.8 其他标记 (54) 总的来说,如果多看看MSDN自身的类库参考,你会发现其实XML文档注释最终形成的就是这样的结果。MSDN本身就是一个最好的XML文档注释的范例,我们可以在实践过程中不断地进行模仿和学习。第7章如何使用函数 (57) 7.1 为什么要使用函数 (57) 7.1.1 函数与方法 (57) 7.1.2 代码复用 (59) 7.1.3 隐藏细节 (61) 7.2 函数重载 (65) 7.2.1 重载的语义 (65) 7.2.2 保持核心代码唯一 (70) 7.3 参数的设计 (75) 7.3.1 参数的命名 (75)

编写具有100%可靠性代码的几个技巧

编写具有100%可靠性代码的几个技巧 您编写的代码是不是虽然在仿真器中表现正常,但是在现场却断断续续出错?要不然就是有可能在您使用更高版本的工具链进行编译时,它开始出错。您检查自己的测试平台,并确认测试已经做到100%的完全覆盖,而且所有测试均未出现任何差错,但是问题仍然顽疾难除。虽然设计人员极其重视编码和仿真,但是他们对芯片在FGPA中的内部操作却知之甚少,这是情有可原的。因此,不正确的逻辑综合和时序问题(而非逻辑错误)成为大多数逻辑故障的根源。但是,只要设计人员措施得当,就能轻松编写出能够创建可预测、可靠逻辑的FPGA代码。在FPGA设计过程中,需要在编译阶段进行逻辑综合与相关时序收敛。而包括I/O单元结构、异步逻辑和时序约束等众多方面,都会对编译进程产生巨大影响,致使其每一轮都会在工具链中产生不同的结果。为了更好、更快地完成时序收敛,我们来进一步探讨如何消除这些差异。I/O 单元结构所有FPGA都具有可实现高度定制的I/O引脚。定制会影响到时序、驱动强度、终端以及许多其它方面。如果您未明确定义I/O单元结构,则您的工具链往往会采用您预期或者不希望采用的默认结构。如下VHDL代码的目的是采用sda: inout std_logic;声明创建一个称为sda 的双向I/O缓冲器。tri_state_proc : PROCESS (sys_clk)BEGINif rising_edge(sys_clk) thenif (enable_in = 1) thensda = data_in;elsedata_out = sda;sda = Z;end if;end if;END PROCESS tri_state_proc;当综合工具发现这组代码时,其中缺乏如何实施双向缓冲器的明确指示。因此,工具会做出最合理的猜测。实现上述任务的一种方法是,在FPGA的I/O环上采用双向缓冲器(事实上,这是一种理想的实施方式)。另一种选择是采用三态输出缓冲器和输入缓冲器,二者都在查询表(LUT) 逻辑中实施。最后一种可行方法是,在I/O环上采用三态输出缓冲器,同时在LUT中采用输入缓冲器,这是大多数综合器选用的方法。这三种方法都可以生成有效逻辑,但是后两种实施方式会在I/O引脚与LUT之间传输信号时产生更长的路由延迟。此外,它们还需要附加的时序约束,以确保时序收敛。FPGA编辑器清晰表明:在图1中,我们的双向I/O有一部分散布在I/O缓冲器之外。教训是切记不要让综合工具猜测如何实施代码的关键部分。即使综合后的逻辑碰巧达到您的预期,在综合工具进入新版本

C#代码--编写高质量C#程序

1.1 换行的讲究 5 1.1.1 寻找最佳的断行位置5 1.1.2 每行只写一条语句7 1.1.3 分行定义变量8 1.2 避免代码过于拥挤9 1.2.1 使用空行分隔代码块10 1.2.2 使用空格降低代码密度13 1.3 如何缩进15 1.3.1 嵌套或包含关系引起的缩进17 1.3.2 因换行而产生的缩进20 1.3.3 使用空格还是Tab键21 1.4 大括号 22 1.4.1 大括号的位置22 1.4.2 空的大括号结构23 1.4.3 仅包含单个语句的结构体26 1.5 保持项目文件的条理性29 1.5.1 解决方案的结构呼应29 1.5.2 代码文件的结构29 1.5.3 使用#region标记32 第2章养成良好的注释习惯33 2.1 何时需要注释33 2.1.1 解释代码的意图34 2.1.2 对局部变量的说明35 2.1.3 充当代码标题36 2.1.4 指出例外情况40 2.1.5 开发提示 40 2.2 注释的格式 41 2.2.1 单行注释42 2.2.2 多行注释44 2.3 正确使用XML文档注释45

2.3.1 结构与类的XML文档注释46 2.3.2 属性的XML文档注释47 2.3.3 方法的XML文档注释49 2.3.4 构造函数的XML文档注释50 2.3.5 事件的XML文档注释51 2.3.6 枚举类型的XML文档注释53 2.3.7 泛型的XML文档注释53 2.3.8 其他标记54 总的来说,如果多看看MSDN自身的类库参考,你会发现其实XML文档注释最终形成的就是这样的结果。MSDN本身就是一个最好的XML文档注释的范例,我们可以在实践过程中不断地进行模仿和学习。第7章如何使用函数57 7.1 为什么要使用函数57 7.1.1 函数与方法57 7.1.2 代码复用59 7.1.3 隐藏细节61 7.2 函数重载65 7.2.1 重载的语义65 7.2.2 保持核心代码唯一70 7.3 参数的设计74 7.3.1 参数的命名74 7.3.2 不要使用保留项74 7.3.3 变长参数列表75 7.3.4 何时使用ref参数和out参数77 7.3.5 参数的顺序78 7.3.6 重载函数的参数一致79 7.4 参数检查82 7.4.1检查零值及空引用83 7.4.2 检查枚举类型84 7.4.3 防止数据被篡改85 7.4.4 在何处检查合法性87 7.5 函数出口88

Verilog语言良好的代码编写格式

Verilog 及VHDL良好的代码编写风格 良好代码编写风格可以满足信、达、雅的要求。在满足功能和性能目标的前提下,增强代码的可读性、可移植性,首要的工作是在项目开发之前为整个设计团队建立一个命名约定和缩略语清单,以文档的形式记录下来,并要求每位设计人员在代码编写过程中都要严格遵守。良好代码编写风格的通则概括如下:(1)对所有的信号名、变量名和端口名都用小写,这样做是为了和业界的习惯保持一致;对常量名和用户定义的类型用大写; (2)使用有意义的信号名、端口名、函数名和参数名; (3)信号名长度不要太长; (4)对于时钟信号使用clk 作为信号名,如果设计中存在多个时钟,使用clk 作为时钟信号的前缀; (5)对来自同一驱动源的信号在不同的子模块中采用相同的名字,这要求在芯片总体设计时就定义好顶层子模块间连线的名字,端口和连接端口的信号尽可能采用相同的名字; (6)对于低电平有效的信号,应该以一个下划线跟一个小写字母b 或n 表示。注意在同一个设计中要使用同一个小写字母表示低电平有效; (7)对于复位信号使用rst 作为信号名,如果复位信号是低电平有效,建议使用rst_n; (8)当描述多比特总线时,使用一致的定义顺序,对于verilog 建议采用 bus_signal[x:0]的表示; (9)尽量遵循业界已经习惯的一些约定。如*_r 表示寄存器输出,*_a 表示异步信号,*_pn 表示多周期路径第n 个周期使用的信号,*_nxt 表示锁存前的信号,*_z 表示三态信号等; (10)在源文件、批处理文件的开始应该包含一个文件头、文件头一般包含的内容如下例所示:文件名,作者,模块的实现功能概述和关键特性描述,文件创建和修改的记录,包括修改时间,修改的内容等; (11)使用适当的注释来解释所有的always 进程、函数、端口定义、信号含义、变量含义或信号组、变量组的意义等。注释应该放在它所注释的代码附近,要求简明扼要,只要足够说明设计意图即可,避免过于复杂; (12)每一行语句独立成行。尽管VHDL 和Verilog 都允许一行可以写多个语句,当时每个语句独立成行可以增加可读性和可维护性。同时保持每行小于或等于72 个字符,这样做都是为了提高代码得可读性; (13)建议采用缩进提高续行和嵌套语句得可读性。缩进一般采用两个空格,如西安交通大学SOC 设计中心2 如果空格太多则在深层嵌套时限制行长。同时缩进避免使用TAB 键,这样可以避免不同机器TAB 键得设置不同限制代码得可移植能力; (14)在RTL 源码的设计中任何元素包括端口、信号、变量、函数、任务、模块等的命名都不能取Verilog 和VHDL 语言的关键字; (15)在进行模块的端口申明时,每行只申明一个端口,并建议采用以下顺序:输入信号的clk、rst、enables other control signals、data and address signals。然后再申明输出信号的clk、rst、enalbes other control signals、data signals;

c语言程序代码编写规范

C语言程序代码编写规范 (初级程序员讨论版) 前言 一个好的程序编写规范是编写高质量程序的保证。清晰、规范的源程序不仅仅是方便阅读,更重要的是能够便于检查错误,提高调试效率,从而最终保证软件的质量和可维护性。 说明 此文挡还在完善改进中,如有不足,欢迎指正。 本文档主要适用于刚刚开始接触编程的初学者。 对于具有一定工程项目开发经验的程序员,建议学习C语言程序代码编写规范 —高级版。 目录 1代码书写规范 2注释书写规范 3命名规范

内容 1 代码书写规范 函数定义 每个函数的定义和说明应该从第1列开始书写。函数名(包括参数表)和函数体的花括号(“{”和“}”)应该各占一行。在函数体结尾的括号(“}”)后面应该加上注释,注释中应该包括函数名,这样比较方便进行括号配对检查,也可以清晰地看出来函数是否结束。 范例1:函数的声明 void matMyFunction(int n) { …… } /* matMyFunction*/ 空格的使用 使用空格分割所有演算符号和操作数。 这条规则的例外是“->”,““.”, “()”和“[]”,这些操作符和操作数之间不空格。 当需要把一个程序行的内容分成几行写时,操作符号应该放在行末,而不是下一行的开头。 缩进的设置 代码书写应该遵从结构化的要求,采用缩进的格式。最小缩进量为4个空格,整个文件内部应该统一,不要混用Tab键和4个空格这两种情况,因为不同的编辑器对Tab键的处理方法不同。 折行的使用 每行的长度不要超过80个字符,当程序行太长时,应该分行书写。 分行时应该按照自然的逻辑关系进行,例如:不要把一个简单的逻辑判断写在 两行上。 分行后的缩进应该按照程序的逻辑关系进行对齐。例如:参数表折行后,下面 的行应该在参数表左括号的下方。 范例2:折行的格式

最新如何编写高质量的Javascript代码 技术 软件

如何编写高质量的J a v a s c r i p t代码技 术软件

如何编写高质量的Javascript代码 技术软件 如何编写高质量的Javascript代码 2011年03月03日|原作者:北玉优秀的Stoyan Stefanov在他的新书中(《Javascript Patterns》)介绍了很多编写高质量代码的技巧,比如避免使用全局变量,使用单一的var关键字,循环式预存长度等等。 这篇文章不仅仅从代码本身来考虑如何优化编码,也从代码的设计阶段来考虑,包括书写API文档,同事的review,使用JSLint。这些习惯都能帮助你编写更加高质量的、更易于理解的、可维护的代码(让你的代码在多年之后仍使你引以为傲)。 编写可维护的代码 软件的BUG修复需要花费大量的精力。尤其当代码已经发布之后,随着时间的增长,维护的成本愈发的高。当你一发现BUG的时候,就立即去修复,这时候你的代码还是热乎的,你也不需要回忆,因为就是刚刚写好的。但是当你做了其他任务,几乎完全忘记了这份代码,这时候就需要: 重新学习和理解问题 理解代码是如何解决问题的 另外一个问题是,在大项目或者大公司里面,经常是解决BUG的人不是产生BUG的人,而且也不是发现BUG的人。所以减少理解代码的时间就是最重要的问题,无论这个代码是你自己以前写的还是团队中的其他成员写的,因为我们都想去搞搞新的有意思的东西,而不是去维护那些个陈旧的代码。

还有一个开发中的普遍问题就是,往往读代码的时间比写代码的时间还要多。有时候你钻研一个问题,可以花整整一个下午的时间来考虑代码的编写。这个代码当时是可以工作的,但是随着开发的进行,其他东西发生了很大的变化,这时候也就需要你自己来重新审查修改编写代码。比如: 还有BUG没有解决 添加了新的功能 程序需要在新的环境中运行(比如一个新上市的浏览器) 代码有问题 代码需要重写因为修改了架构甚至要使用另一个语言 因为这些原因,也许你当时一个下午写好的代码,后面需要花费几周的时间来阅读。所以编写可维护的代码对于软件的成功至关重要。 可维护的代码包括: 可读性 连续性 预见性 看起来是一个人写的 有文档 最少化全局变量 Javascript使用函数来约定作用域。一个在函数内部声明的变量在外部是不可见的。所以,全局变量也就是声明在任何函数之外的或者没有被声明的变量。

相关主题
相关文档 最新文档