前言:

        总结,开发过程中的各种好习惯,不仅仅是写代码的时候,还有各种其他情况。都可以做的好一点。

一,代码各种规范优化

案例1(你猜

大师兄

这段代码暂时有如下三个问题:

1,代码注释不规范:类注释,变量注释,属性注释的格式都是有要求的。

2,//这个注释,还是仅挨着代码比较好

3,new 文件了,没有try catch 这是会抛异常的。

    (小问题吗?NO,关不掉资源,会OOM的)

大师兄

下面是实际上他们写的,因为关闭文件流姿势不对,已经导致OOM的实际例子。

大师兄

不要等到OOM了,,才发现,哦原来是这点小事情,搞的大bug呀。

 

案例2

大师兄

不推荐为了省地方,一行声明几个变量。看着非常的不得劲。

大师兄

如图所提示的那样。

案例3

大师兄

1,首先,不推荐使用fori循环,而是使用foreach循环

2,坚决反对a.b.c.d.e这种一连串的调用方法,分分钟空指针异常,都不知道哪空指针了。

3,在代码进行的每一步,都需要判断下你使用的这个对象是不是null,不要觉得这个肯定不是null,就省掉这个判断。因为你没有达到一定的高度,看不到远方。下面就是很好的例子。

大师兄

默认觉得这个在上面的if else语句里面,肯定是赋值了,在使用的时候,就没判断null,然后,真的就出空指针异常了。(出空指针bug,是很low的呀,说明你在写代码的时候,考虑问题不全面。要是考虑全面了,即使null,你代码里面也对应的策略。也不至于报NPE。)

 

案例4

代码可以不写,注释一定要写。

大师兄

修改了代码,代码注释也应当一并更新。

大师兄

新建的枚举类型,每个枚举都是干啥的,一定要写注释。

大师兄

不写注释是很不好的习惯,害人害已。

美国出现过程序员因为不写注释,被同事枪杀的新闻。

大师兄

大师兄

属性注释姿势不对

大师兄

方法的注释的姿势不对

新建个model,只有新建的人知道你这个model是干啥的,类,属性,方法都是一定要写注释的。而且注释也要按正确格式写。

属性的注释,类的注释,方法的注释,参数的注释,返回值的注释,异常的注释,方法内部的代码说明。都请按正确的姿势,写注释。

不然到时候,接盘的人要问候你全家的。不要觉得话难听,事实就是如此。

案例5

大师兄

大师兄

应当使用驼峰法命名变量名。

 

案例6

大师兄

不能在行尾注释

 

案例7

大师兄

@override,这个注解,不要省略。

 

案例8

不要觉得方法简单,就直接使用,而不是封装方法。

大师兄

不推荐这么直接使用dao去find,而是应该使用封装的方法。降低dao使用的地方。这样如果升级数据库版本的时候,就只需要改封装的方法,而不是去找所有使用dao变量的地方,降低维护难度。

大师兄

 

案例9
不要做无谓的省略,表觉得这个省略高大上。

大师兄

大师兄777

if等都记得带上括号,不要因为不带括号性能会有提高,就省略这个括号。

代码规范些,方便你我他。方便阅读。

这种代码,我估计年轻人是不会写的,因为年轻人在受教育的时候,推荐的就是写完整的,都是一些上了年纪的才这么写。

就比如上图中的,if 写在一行的,还带return的,这绝壁不是年轻人的手笔。

 

案例10

大师兄

这个变量名称取的稍微有点问题,看不出来是个复数,复数的还是带上s好,意思明确。

这个也不是很大的问题,就是代码阅读的时候好点儿。

 

案例11

大师兄

1,StreamIds变量的命名不符合通用规范

2,这个返回的变量的声明,显得多余,可以直接return。

 

案例12

大师兄

全是service的文件夹下,出现个不是service的model bean,很不和谐的画面,应当将相同功能的文件,分类到各自的目录下。

 

案例13

大师兄

建议如图所示,原因,大写的L和小写的l的区别,人眼看l和1很相似,虽然计算机是不会搞错的。为了方便代码阅读还是使用大写的L比较好。同理double的时候也推荐使用大写的D而不是小写的d。

 

案例14

大师兄

案例15

大学生

一个方法推荐是不要超过80行。

代码写的急的话,这个肯定就当作没看见了,但是代码超过80行,说明代码里面肯定提出来单独写个方法的,然后可以通用的。

 

案例16

关于线程池的使用的建议。

案例17

1,看到图上的红色的大于号没? >

2,变量的命名

代码样式很丑,要是条件再多点,这个大于号还会再大。如下

应当如何写,才好看点呢

大师兄

消灭大于号,让代码看着好看点。

 

案例18

1,类名称首字母应当大写

2,model的属性的注释姿势不规范

3,阿里巴巴规范有如下提示,int和Integer的差别。int不会空指针,但是int类型不能null这个会在传参数的时候可能出问题。

这个int和Integer会出问题,主要是在作为请求的参数的时候,int类型的这个参数就不能省略,省略了,就会出现400的错误码,但是Integer类型的,即使省略啦,那值就是null,就不会出现请求400的错误。

 

案例19

一个类里面有这么多的黄色和红色警告,本身就是代码不规范的表现,见到这些个警告,咱还是能看看的就给看看,因为这个是历史原因,不好整了,但是自己在新做的时候,确实需要注意一下这个代码警告。尽量不要出现这些黄色的红色的灰色的警告。这样子,代码看着也舒服点。这个是idea这个编辑器给提示的。eclipse有没有类似的功能,就不知道啦,还是建议使用idea这个高科技编辑器。

案例20

这估计就是手一抖,包就引进来了,也没在意引用的到底是谁。

还是稍微考虑一下,这手随便一抖,给后面的维护带来了点点的麻烦。

要说也不能算手抖,可能引用的老铁,不晓得这个jar的作用吧,以及这个jar的出处。

关于引用的优化,这个引用,是A被底层自定义项目B引用,然后B又被项目C引用,在C项目里面A相关的东西的时候,这样的话,方便解耦合。

 

案例21

回车键了解一下。

能把代码一行写这么长的,还能忍住不换行的,都是大哥。我们应该包容点。看代码的时候除了上下滚动下滑轮,顺便还可以左右拖动一下下面的滚动条,活动活动思想和身体,也是为看代码的你考虑周到呀。

 

案例22

2个代码一个意思,但是,上面的代码写出来,好像高大上似的,但是,根本不利于代码阅读。也不美观。

 

案例23

1,case里面不应该直接是字符串常量,

2,switch case里面default不可少,要是条件都不符合几个case的情况怎么办。不能说,我不考虑default情况,就不写,必须写,这些是规范。

 

案例24

测试的main方法都提交了,估计是某次任务改的文件太多了。给搞忘记了。不科学。

eclipse的锅。

建议使用idea,他的version control 很科学的,把所有的修改的文件都集中在一起,还可以对改过的文件进行分组。等等,好处是谁用谁知道。不用不知道。

你把这个提交了,要是要求严格的公司,这算事故。代码提交能这么随意的吗?

 

案例25

1,这个map的描述是里面放的是用户名当作map的key,但是实际put的时候,这个key变化了,不单单是用户名这么简单了

2,map在put的时候,key应当简单点,把这个一连串操作弄出去弄个变量。方便阅读

3,用户名username,额这个单词居然是对的。

 

案例26

spring中如下使用成员变量,然后在代码里面修改,然后就线程安全问题啦。

然后这个map里面理论上一个用户put一次的。但是这个debug截图,admin用户put了2次

所以:结论是,spring容器管理的bean默认都是单例模式。禁止使用可变的成员变量

(即使是final,他的内容也是可变的,然后就线程不安全啦。)

 

案例27

文件流的正确关闭

难道老兵们,都不在意这个文件流的正确姿势关闭吗?

如果这个文件流没被关闭的话,内存一直被占用,服务器会宕机的呀。

上面不止一次说这个问题啦。

这真的是看别人提交的代码里面,很随意关闭文件流的截图,,,,唉,都不当回事儿。都觉得这不是事儿。。。。

 

案例28

一个Javaclass里面,竟然声明里如此多的变量、常量、等等。

而且还是干干净净,丁点儿注释都不舍得写的。

咱能稍微有点分类的思想吗?

常量,统一到一个interface里面去,配置呢,就弄过配置对象。

分类一下,代码也好看,也好理解,也好修改和扩展。也好写注释呀。

 

案例29

这个不好一眼发现问题。

这个方法里面每次都会去创建一个连接es的client。

当这个方法被n次调用之后,bug就出现了。

提示,实际开发的时候,对于这种对外的连接,需要创建单例。确保安全。

 

案例 30

通常发生在做新功能的时候,复制粘贴太快了,然后呢,就会出现,复制过来的代码,有的连方法名字都懒得改的,还有就是这样的,字符串信息,还是原来的,这在排错的时候,那可就悲剧啦,使劲往坑里走呀。明明是这的错,却指引着你往那去。那可不就悲剧了么。

 

案例31

对于这种抽象方法,抽象接口啥的,idea会使劲提示你写注释的,

但是吧,有的老铁内心OS:我就是没看见,哎,我就是不写,你能把我咋地呀。

不能把你咋的,但是,咱还是推荐,你麻烦写一下你这方法是干啥的。OK不?

 

二,其他的一些优化

案例1

配置文件或者分支的名字,不要仅仅取每个汉字的首字母

因为这个分支或者这个配置文件又不是分分钟测试一下就删掉了。你看着首字母,当时正做你的任务,你肯定知道这个缩写啥意思,但是,过段时间后,或者team的其他成员,他怎么知道你做了什么任务,怎么了解你的缩写啥意思。表说svn记录上有,难道我把每个项目都下载下来,看看你当时的提交记录么?

这就跟变量的命名一样,要见名知意。不要觉得啰嗦,不要觉得拼音low,蹩脚的英文更low,还可怕。

 

案例2

配置文件,这东西不少项目都少不了,那么就会存在一个问题,

今天a加了个配置,明天b加了个配置,都如上那样一直加加加的

直到有一天,小d来了,哦豁,一看配置文件,起初几k的文件都快上M了(夸张了点)

请问,这个小d如何知道这个几M的配置文件里面的每一行都是啥意思呢?

答案只有一个:

“你去看代码呀,不都写在代码里的吗”!!!!!!!!!!!!!!!!!!!!!!

小d可开心啦,要把整个项目都给看一下,

然后,悲催的发现,代码也是干干净净,丁点儿注释都不舍得写的那种

还能怎么办呢,还是那句话:“你去看代码呀,不都写在代码里的吗?”

哦,这个配置是这意思,那个配置是那个意思,,,,,,

从少年到白头,估计差不多啦。

大家都是自己人,何苦互相为难呢。

咱多写几句注释会死吗!你好我好大家好呀。你说是不是。


发布评论
IT序号网

微信公众号号:IT虾米 (左侧二维码扫一扫)欢迎添加!

Java 代码优化:关于 说“try catch 放在 for/while 循环之外,会提高效率 优化代码”的测试知识解答
你是第一个吃螃蟹的人
发表评论

◎欢迎参与讨论,请在这里发表您的看法、交流您的观点。