改善Java程序的151个建议 1-5章

改善Java程序的151个建议 1-5章

建议1:不要在常量和变量中出现易混淆的字母

建议2:莫让常量蜕变成变量

image-20210730132124986

RAND_CONST是常量吗?它的值会变吗?绝对会变!这种常量的定义方式是极不可取的,常量就是常量,在编译期就必须确定其值,不应该在运行期更改,否则程序的可读性会非常差,甚至连作者自己都不能确定在运行期发生了何种神奇的事情。

建议3:三元操作符的类型务必一致

image-20210730133141702

三元操作符类型的转换规则

  • 若两个操作数不可转换,则不做转换,返回值为Object类型。
  • 若两个操作数是明确类型的表达式(比如变量),则按照正常的二进制数字来转换,int类型转换为long类型,long类型转换为float类型等。
  • 若两个操作数中有一个是数字S,另外一个是表达式,且其类型标示为T,那么,若数字S在T的范围内,则转换为T类型;若S超出了T类型的范围,则T转换为S类型(可以参考“建议22”,会对该问题进行展开描述)。
  • 若两个操作数都是直接量数字(Literal[插图]),则返回值类型为范围较大者。

建议4:避免带有变长参数的方法重载

变长参数的优缺点

  • 可以提高方法的灵活度和可复用性
  • Java5之前常用的设计技巧就是把形参定义成Collection类型或子类类型,或者数组类型
    • 缺点:需要对空参数进行判断和筛选,比如参为null值和长度为0的Collection或数组
    • *:Java5以后引入变长参数

变长参数定义规则

  • 变长参数必须是方法中的最后一个参数
  • 一个方法不能定义多个变长参数

重载的定义

方法名相同,参数类型或数量不同

错误示例

问题在:

​ 变长参数的范围覆盖了非变长参数的范围

提问

对于calPrice(49900,75)这样的计算,到底该调用哪个方法来处理呢?

image-20210730134843990

改善建议

​ 问题是阐述清楚了,为了让我们的程序能被“人类”看懂,还是慎重考虑变长参数的方法重载吧,否则让人伤脑筋不说,说不定哪天就陷入这类小陷阱里了。

建议5:别让null值和控制威胁到变长方法

问题代码

image-0210730135827526

问题是

  • 两处提示是相同的:方法模糊不清,编译器不知道调用哪一个方法
  • 但是两处代码反应的代码味道可是不同的

问题在

  • 对于methodA(“China”)方法,是Client类的设计者,违反了KISS原则(Keep It Simple,Stupid,即懒人原则),按照此规则设计的方法应该很容易被调用。调用者调用methodA(“China”)是符合规范的,但是现在却出错了,因为两个方法都符合形参格式,编译器不知道调用哪个方法。
  • 对于client.methodA(“china”,null)方法,直接量null是没有类型的。虽然两个方法都符合调用请求,但是不知道调用哪个,于是报错了。
    • 出错有:不符合懒人原则
    • 还有一个非常不好的编码习惯:即调用者隐藏了实参类型,这是很危险的,不仅调用者需要猜测该调用哪个方法,而且被调用者也可能产生内部逻辑混乱的情况
    • 对于本例来说,应做如下修改:
      隐藏了实参类型,这是很危险的,不仅调用者需要猜测该调用哪个方法,而且被调用者也可能产生内部逻辑混乱的情况
    • 对于本例来说,应做如下修改:
      • image-20210730140723893
  • 1
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 1
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

打赏作者

赞一下鼓励

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

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

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

打赏作者

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

抵扣说明:

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

余额充值