代码规范 任重而道远

1 代码规范化的意义

  1.1软件维护是软件生命周期中持续时间最长的阶段。因此代码总会被很多人去维护,规范的代码可以减少维护人员的理解时间,降低维护代价,方便进行二次开发

  1.2几乎没有任何一个软件,在其整个生命同期中,均由最初的开发人员来维护,所以作为最初的你最好留下好的口碑

  1.3编码规范可以改善软件的可读性,可以让程序员尽快而彻底地理解新代码

  1.4建议性的规范帮助编码人员写出易理解、易维护、易扩展的优秀代码

2 编码规范指南

  2.1排版规范

    2.1.1程序块采用缩进,缩进空位为4个

    2.1.2分解符如“{”和“}”独占一行,并且位于同列

    2.1.3较长的语句、表达式、参数要书写多行

    2.1.4一行只写一条语句

    2.1.5if,for,do,while,case,switch,default 独占一行,且语句块都要加“{ }”,无论语句多少

    2.1.6相对独立的业务语句块之间,变量说明后加空行

    2.1.7对齐只用空格不用TAB,避免不同编辑器对TAB处理不同

    2.1.8对二个以上的关键字、变量、常量进行对等操作时,变量前后必须留空格,如果if( a == b)

    2.1.9类属性和方法不用交叉放置,不同存取范围的属性或方法也不远交叉放置

  2.2注释规范

    2.2.1有代码的地方就有注释,杜绝没有任何注释的代码,推荐注释量在20%以上

    2.2.2包的注释:在包的当前路径放入一名为package.html的HTML文件,方面JavaDoc收集。注释内容简述本包的作用、内容、产品模块、版本、版权等

    2.2.3文件注释:文件开始,package 关键字前面,记载版权说明、描述信息、生成日期、修改历史

    2.2.4类和接口的注释:在package之后,class或interface之前,描述当前类或接口的功能,作者,生成日期,修改日志,版本号等

    2.2.5类属性、方法注释:在类或方法的前面,类属性记载属性的功能用处,用/* 开头描述注释,放置JavaDoc收集;

    2.2.6类方法注释需要记载方法的功能简述、详细、输入参数、输出值、抛出的异常、作者等

    2.2.7类方法内部注释: 注释应放置被注释语句的正上方或右侧; 注释必须与被注释的语句同缩进; 注释与上面的代码只有用一个空行隔开; 属于同一业务逻辑块的代码,须显示注释用途; 对于变量定义和分支语句(if, switch, case)必须注释; 写代码的同时写注释,修改代码的同时,也修改注释; 注释块内部请不要加缩进; 注释内容内部需要着重提示的,请包括标签<b>xxxx</b> 对于业务逻辑比较多的方法,建议显示注释步骤1、2,、3、4… 注释含义明确,不要写无意义的注释和难以理解的词汇

  2.3命名规范

    2.3.1包的命名:常用命名方式:com.公司名.产品线名.项目名.模块名,所有名称全部小写

    2.3.2类名和接口名的命名:尽量使用完整的英文描述,首字母大写,每个英文单词的首字母大写,其余字母小写。抽象类请以Abstract开头,接口的实现类请以Impl接口,工具类请以Util或Utils结尾,如下列命名方式: StaffService、DefaultStaffService、AbstractEntity、StringUtils;

    2.3.3、方法命名;尽量使用完整的英文描述,首字母小写,每个英文单词的首字母大写,其余字母小写,属性存取尽量使用setX、getX,返回布尔类型值的方法尽量使用isX,如下列命名方式: queryStaffById、isCodeExists()、getValue

    2.3.4、属性命名;尽量使用完整的英文描述,首字母小写,每个英文单词的首字母大写,其余字母小写,属性名和方法名不要重复;

    2.3.5、常量命名;使用全部大写的英文描述,每个单词之间用下划线分隔,变量之前近可能使用final修饰,注意:枚举也是一种常量;

    2.3.6、模块内部的组件,尽量以组件名开头,如:StaffDAO、StaffService;

    2.3.7、组件命名,尽量以组件类型结果,如:StaffService、OrgService;

    2.3.8、准确控制类成员方法的修饰符,如果仅限于类内部使用用private修饰,可供子类或本包内部使用用protected修饰,对所有公开,则用public;

    2.3.9、属性和方法的命名不易过长,一般不超过15个字母;

3 怎样写规范的代码

    包结构清晰,类、接口、方法、属性命名贴切易懂;

    该注释的地方注释,注释清楚、易懂,没有二义性;

    接口定义明确,精确方法功能,每个方法只实现一个功能;

    方法内部的代码行数控制在200行以内,一个类的代码行数控制在1000行以内,如果你的类代码在1000行以上,请重新思考设计思路,这里说的代码行数不把注释计算在内;

    多个方法内部如果有相似的功能代码块,应该提取为公用方法;

    尽量将业务相近的方法放在一起,便于寻找;

    方法内部尽量不要catch异常,让外部调用者知道出错细节;

    方法内部对于对象参数的调用,尽量判断非null引用,除非你的设计能保证非空对象;

    不用的数据及时是否,如果数据库连接、集合、共享锁等;

    不要使用技巧性比较高的表达式;

对于方法抛出的自定义异常,应该写明异常描述信息;

评估你的数据,对变量采用合理的类型,如一个整数在1个字节8位以内,应该使用byte;

该用基本数据类型就用基本数据类型,明确告诉虚拟机你的数据类型,避免虚拟机帮你做类型转换

红色标识 自己碰到过的需要改正的毛病

任重而道远!

附PSP

Job Type Data Start End Total(min)
效能 编码测试 3.13 14:30 15:20 50
效能随笔 随笔
3.14

3.15


14:20

10:40


14:51

10:50

41

了解燃尽、

甘特、鱼刺图

查阅 3.15 19:05 19:50 45
软件对比分析 随笔 3.16 13:50 14:35 45
小组工程需求讨论 讨论 3.16 17:50 19:50 120
代码规范 查阅 3.16 21:05 21:30 25
总结随笔 随笔 3.16 22:30 23  

工作量表

  代码行数 博客字数 知识点
第二周 0 2500
代码规范

工程控制

需求分析

效能分析

写在最后

在这个课程中与“耐撕”一起完成抢答器项目,争取在实践中充分了解软件工程的过程。加油!

时间: 2024-10-13 00:50:54

代码规范 任重而道远的相关文章

作业三: 代码规范、代码复审、PSP

(1) 是否需要有代码规范         1.这些规范都是官僚制度下产生的浪费大家的编程时间.影响人们开发效率, 浪费时间的东西.(反对) 答:首先编码规范 包括了编码风格和其它规范 一个团队遵守一些规范有很多的好处! (1). 遵守编码风格使代码更容易维护 (2). 编码风格使形成代码集体所有制(集体所有制的作用很大,它能有效的增大巴士因子——一个项目能承受多少个程序员被车撞了而不影响项目的正常进行) (3). 编码风格能消除那些长久的纷争(你不需要喜欢这种编码风格.如果你不喜欢里面的某条规

两人合作之代码规范

代码规范 现代软件经过几十年的发展,一个软件由一个人单枪匹马完成,已经很少见了,软件都是在相互合作中完成的.合作的最小单位是两个人,两个工程师在一起,做的最多的事情就是"看代码",每个人都能看"比人的代码",并且发表意见.但是每个人对于什么是"好"的代码规范未必认同,这时我们有必要给出一个基准线-----什么是好的代码规范和设计规范. 1,写干净整洁的代码 1.1 代码格式化,包括多级代码缩进.大括号(比如C系代码),为了提高代码的美观型和易读性

代码规范的重要性

一个规范的代码,通常能起到事半功倍的作用: 一.规范的代码可以促进团队合作 一个项目大多都是由一个团队来完成,如果没有统一的代码规范,那么每个人的代码必定会风格迥异.且不说会存在多个人同时开发同一模块的情况,即使是分工十分明晰的,等到要整合代码的时候也有够头疼的了.大多数情况下,并非程序中有复杂的算法或是复杂的逻辑,而是去读别人的代码实在是一件痛苦的事情.统一的风格使得代码可读性大大提高了,人们看到任何一段代码都会觉得异常熟悉.显然的,规范的代码在团队的合作开发中是非常有益而且必要的. 二.规范

最详细的 Swift 代码规范指南

1. 代码格式 1.1 使用四个空格进行缩进. 1.2 每行最多160个字符,这样可以避免一行过长. (Xcode->Preferences->Text Editing->Page guide at column: 设置成160即可) 1.3 确保每个文件结尾都有空白行. 1.4 确保每行都不以空白字符作为结尾 (Xcode->Preferences->Text Editing->Automatically trim trailing whitespace + Incl

项目经理的管理技巧-代码规范

一.系统里面存在的糟糕代码情况有: 1. 代码规范,命名规范和注释 2. 公用代码的抽取和封装 3. 性能低下的代码 4. 表现层.业务层.数据持久层位置存放混乱问题 二.问题 岗位调动,接手一个新的项目组.旧项目一踏糊涂,全部无规范和设计. 组成员各做各的,毫无团队协作能力,更别说团队凝聚力.简直不能更糟糕. 新项目.新成员,新项目重新做了明确规范和框架设计,但组员很多时候不能很好的按照规范进行开发 我有强迫症  三.开始犯的错误,也是最笨的做法 定时核查,自己看到不正确代码同时指出,让开发优

软工学习笔记——代码规范

上大学以来写了这几年的代码,却一直没怎么关注过代码规范相关的问题,直到软工课上讲了之后,才开始有所顾及.上课的时候回头看看自己写过的那些代码,真是丑死了,几个月前自己写的代码现在就已经读不懂了. 看了书上的相关章节,对于我来说,我觉得我的代码主要注意这几点: 1. 少写冗余代码,已经用不到的代码段就应该删去.(我今天刚刚发现我的昆特牌Online项目中竟然还存在有两个没用的类) 2. 多利用空行来将代码小规模地分段. 3. 大段的无用代码不要一直注释着,该删就删.(我的项目里经常会有一大堆没用的

代码规范

1.这些规范都是官僚制度下产生的浪费大家的编程时间.影响人们开发效率, 浪费时间的东西 一个项目大多都是由一个团队来完成,如果没有统一的代码规范,那么每个人的代码必定会风格迥异.且不说会存在多个人同时开发同一模块的情况,即使是分工十分明晰的,等到要整合代码的时候也有够头疼的了.大多数情况下,并非程序中有复杂的算法或是复杂的逻辑,而是去读别人的代码实在是一件痛苦的事情.统一的风格使得代码可读性大大提高了,人们看到任何一段代码都会觉得异常熟悉. 2.我是个艺术家,手艺人,我有自己的规范和原则 每一个

作业三:代码规范

对于是否需要有代码规范,请考虑下列论点并反驳/支持: 1. 这些规范都是官僚制度下产生的浪费大家的编程时间.影响人们开发效率, 浪费时间的东西. 对于以上观点我是反对的 .如果说这些规范都是官僚制度产生的,那么更应该一丝不苟的执行,官僚制度,往大了说是法,应该无条件执行,往小了说是规范,可以帮助我们规范在打代码时自身不好的习惯.也许在编辑代码时,会比随意敲打耽误些许时间,但在检查错误时,规矩的编排格式,可以一目了然的看到自己的错误,为自己节省了更多的时间,会提高开发效率. 2. 我是个艺术家,手

作业三 (一) :是否需要有代码规范

这个作业主要是讨论代码规范的,围绕以下几个问题讨论 1.这些规范都是官僚制度下产生的浪费大家的编程时间.影响人们开发效率, 浪费时间的东西. 答:首先编码规范 包括了编码风格和其它规范 一个团队遵守一些规范有很多的好处! (1). 遵守编码风格使代码更容易维护 (2). 编码风格使形成代码集体所有制(集体所有制的作用很大,它能有效的增大巴士因子——一个项目能承受多少个程序员被车撞了而不影响项目的正常进行) (3). 编码风格能消除那些长久的纷争(你不需要喜欢这种编码风格.如果你不喜欢里面的某条规