Java代码规范

命名规范
1.名字应该能够标识事物的特性,并且与业务挂钩。
2.名字一律使用英文单词,而不能为拼音。
3.名字可以有两个或三个单词组成,但不应多于4个,控制在3至30个字母以内。
4.在名字中,多个单词用大写第一个字母(其它字母小写)来分隔。例如:IsSuperUser。
5.命名避免和以下关键字冲突
如:Base,Date,Class……
6.方法名、参数名统一使用驼峰命名法(Camel命名法),除首字母外,其他单词的首字
母大写,其他字母小写,类名每个组合的单词都要大写;
正例:localValue/getHttpMessage()/inputUserId

注释规范
1.一般情况下,源程序的有效注释量必须在30%以上。
2.避免使用装饰性内容,保持注释的简洁。
3.注释信息不仅要包括代码的功能,还应给出原因,不要为注释而注释。
4.除变量定义等较短语句的注释可用行尾注释外,其他注释当避免使用行尾注释。
5.注释类型:javadoc注释,失效代码注释(eclipse下ctrl+shift+/),代码细节注释//。
6.对类、方法、变量等的注释需要符合JavaDoc规范,对每个类、方法都应详细说明其
功能、条件、参数等,并使用良好的HTML标记
7.格式化注释,以使生成的JavaDoc易阅读和理解。
8.如果注释太复杂说明程序需要修改调整,使设计更加合理。
9.getter、setter方法不用注释
10.注释不能嵌套
11.生成开发文档的需要用中文编写
12.如果需要注释的内容太多,需附加文档进行说明,注释时加上"参见《****》"
13.距离较远的}必须注释
14.复杂的分支流程必须注释
15.代码质量不高但能正常运行,或者还没有实现的代码用//TODO:声明
16.存在错误隐患的代码用//FIXME:声明

语句规则
原则:

1.统一使用Eclipse格式化工具进行格式化,默认快捷键:Ctrl+Shift+F
2.尽量避免强制类型转换。如果不得不做类型转换,尽量用显式方式。
3.Ifelse中的业务代码行数太长,否则就要考虑用函数封装
4.避免在表达式中用赋值语句
5.避免对浮点类型做等于或不等于判断
6.杜绝魔法数字,for循环的最大数等也要用变量代替,以便知道是什么含义
7.对象比较运算,常量放在前面,比如"aaa".equals(str)
8.Boolean的"假"判断格式:if(false==isMax)而不用if(!isMax),因为非符号"!"不
清晰
9.如果一段带有业务逻辑的代码超过两次用到,就将其封装成一个方法
10.单个循环也要用{}
11.每个变量仅有一个唯一的用途
12.单个函数执行单个功能并与其命名相符
13.消除所有编译器警告
14.常数变量声明为final
15.每个if-elseif-else语句都有最后一个else以确保处理了全集
16.对于流操作代码的异常捕获有finally操作以关闭流对象,比如:
在这里插入图片描述
17.对同步对象的遍历访问必须进行代码同步处理
18.在对Map对象使用迭代遍历过程中保证没有做增减元素操作
19.Ifelse判断语句避免头重脚轻,比如if的代码段过大,else的代码很短,这时候要调
整结构。
20.每一行最多包含一条语句。

循环语句:
1.务必检查,杜绝死循环
2.即使循环体只有一条语句,也要用花括号括起
3.尽量不用空语句,特殊情况用到空语句,写好注释,告诉读者这不是bug
4.循环中禁止使用访问数据库的操作,循环内部如果需与数据库交互,而应提前一次性
读取出。
比如:Switch-case
1.语句switch中的每个case各占一行。
2.所有的非空case语句必须用break;语句结束。例:
在这里插入图片描述
3.语句switch中的case按字母顺序排列。
4.为所有switch语句提供default分支。

编码风格规则
编码过程中需遵循以下风格习惯:
1.代码未写,文档先行,注释必须按照固定统一范式撰写。
2.关系运算必须常量在左、变量在右。
3.不许使用复杂的运算表达式,必要时添加括号而不依赖于优先级。
4.局部变量必须初定义、避免不必要的内存操作、内存操作必须考虑异常处理。

代码规范比比皆是,但是很少有公司做好代码规范的。忍不住想谈谈代码规范的重要性,希望所有人都能够重视起来。而且,我相信,如果我们代码规范能够做好的话,且不说开发水平提高多少,至少我们也会有很多出色开源项目。 一、规范代码可以促进团队合作 一个项目大多都是由一个团队来完成,如果没有统一的代码规范,那么每个人的代码必定会风格迥异。且不说会存在多个人同时开发同一模块的情况,即使是分工十分明晰的,等到要整合代码的时候也有够头疼的了。大多数情况下,并非程序中有复杂的算法或是复杂的逻辑,而是去读别人的代码实在是一件痛苦的事情。统一的风格使得代码可读性大大提高了,人们看到任何一段代码都会觉得异常熟悉。显然的,规范代码在团队的合作开发中是非常有益而且必要的。 二、规范代码可以减少bug处理 很多IT人士将程序员比做民工,这也的确非常的形象。就像刚才提到的,复杂的算法或逻辑只占项目中很小的比例,大多仅仅是垒代码的工作。可是越是简单,测试的bug反而是越多,而且是无穷无尽的bug。这很大的程度上是由于代码规范所致。 没有规范的对输入输出参数的规范,没有规范的异常处理,没有规范的日志处理等等,不但导致了我们总是出现类似空指针这样低级的bug而且还很难找到引起bug的原因。相反,在规范的开发中,bug不但可以有效减少,查找bug也变得轻而易举。 规范不是对开发的制约,而确实是有助于提高开发效率的。 三、规范代码可以降低维护成本 随着我们项目经验的累积,会越来越重视后期维护的成本。而开发过程中的代码质量直接影响着维护的成本。因此,我们不得不从开发时便小心翼翼。 在第一点中曾提到,规范代码大大提高了程序的可读性,几乎所有的程序员都曾做过维护的工作,不用多说,可读性高的代码维护成本必然会大大降低。 但是,维护工作不仅仅是读懂原有代码,而是需要在原有代码基础上作出修改。我们可以先想像没有统一风格的情况下,A完成开发以后,B进行维护加一段代码,过一段时间C又加一段代码。。。。。。直到有一天X看到那一大堆乱码想死的心都有了,维护也就进行不下去了。因此,统一的风格有利于长期的维护。 另外,好的代码规范会对方法的度量、类的度量以及程序耦合性作出约束。这样不会出现需要修改一个上千行的方法或者去扩展一个没有接口的类的情况。规范代码对程序的扩展性提高,无疑也是对维护人员的一个奖励。 四、规范代码有助于代码审查 我个人是比较赞同进行代码审查的,这样可以及时纠正一些错误,而且可以对开发人员的代码规范作出监督。团队的代码审查同时也是一个很好的学习机会,对成员的进步也是很有益的。但是,开发随意,加重的代码审查的工作量及难度,并且使得代码审查工作没有根据,浪费了大量的时间却收效甚微。 代码规范不仅使得开发统一,减少审查拿督,而且让代码审查有据可查,大大提高了审查效率和效果,同时代码审查也有助于代码规范的实施。一举多得,何乐而不为呢。 五、养成代码规范的习惯,有助于程序员自身的成长 即使明白代码规范的好处,但是有的迫于项目压力,有的因为繁琐的规范作出很多额外的工作,更有的不重视维护的问题,而很难贯彻代码规范。 那么,我们需要了解,规范开发最大的受益人其实是自己! 你有没有花费很多的时候查找自己的代码呢?尤其是出现bug的时候需要逐行的debug?自己写的代码乱了头绪的确实也见了不少。我们应该做的就是规范开发,减少自己出现的错误。很多时候项目的压力一部分也是由于前期开发中遗留的众多的问题。 还有的人觉得自己可以完成高难度的算法,就认为自己能力很强,不把规范放在眼。很多人确实是这样,追求个性,大概让别人看他的代码一头雾水更觉得得意。殊不知复杂的算法确实可以体现你个人的逻辑能力,但是绝不代表你的开发水平。我们知道一些开源项目,一些大师级人物写得程序都是极其规范的。并非规范了就代表高水平,实际上是规范代码更有利于帮助你理解开发语言理解模式理解架构,能够帮助你快速提升开发水平。不明白这点,即使你写的再高明的算法,没准哪天也被当作乱码别处理掉。 记住!每天垒乱码(或许你不觉得,但是大多时候在别人眼中确实就是乱码)并不能使你获得更多的进步,相反要达到高水平的程序员,养成良好的开发习惯是绝对必需的。 不要沉迷表面的得失,看似无用的东西要经过慢慢的累积由量变达到质变的时候,你才能感受到其价值所在。 最后提醒一句,制定一个符合自己公司情况的开发规范是很简单的,重要的是我们能够认识到规范的重要性,并坚持规范的开发习惯。
评论 16
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

孙正嗯大正

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值