访谈:Java Equals

Sup*_*Man 36 java

我在面试中被问到这个问题.以下哪项更好用

 MyInput.equals("Something");   
Run Code Online (Sandbox Code Playgroud)

要么

"Something".equals(MyInput);
Run Code Online (Sandbox Code Playgroud)

谢谢

Jig*_*shi 59

我会去的

"Something".equals(MyInput);
Run Code Online (Sandbox Code Playgroud)

在这种情况下,如果MyInput是,null那么它将不会抛出NullPointerException

在这里,我们确定equals()将要调用的对象是NOT NULL.

如果你希望NullPointerException你的代码做出一些决定或抛出/包装它,那么首先去.

没有性能影响

  • 如果一个变量是'null`并且我不期望它是,那么我宁愿快速失败并被异常告知,而不是静默失败,或者可能是一个更难以调试的方式.第一个是更具可读性和自然性,是良好代码的重要组成部分. (12认同)
  • 我不相信这样的答案有这么多的赞成,并被认为是正确的!这是写在它上面的不好的做法 - 将变量/常量值切换为AVOID NullPointerException是一种可怕的方式,可以将潜在的疯狂行为引入生产.如果您希望输入为null,则在字符串比较之前检查它.如果您从未期望它为null,那么这需要在您的应用程序中煞费苦心,以便您可以调查导致此null值的可能用户故事并相应地对其进行处理. (2认同)

Rya*_*des 21

成为逆势者...... :)

如果MyInput为null,则第一行可能会崩溃,但这只是一个代码方便的程序员(通常使用C宿醉),当他们不想断言"MyInput"可以为null时.

如果使用第二个选项,那么这行可能不会导致NullPointerException,但可能会出现以下行.

我相信更好地了解变量的可能状态,而不是依赖一些能够减轻你良心的代码构造.

  • 我曾经用`null`地毯清扫方式写作.但是,当我启动Java时,我曾经接受`null`来表示一个空集合.NPE太常见了.在代码的上下文中,`null`是没有意义的.因此,更喜欢避免`null`s,这意味着检查.并且,在这里相关,不要试图扫除地毯下的任何错误. (5认同)
  • 如果你知道`myInput`可能是`null`,那么告诉读者通过编写`myInput!= null && myInput.equals("Something")`.它更长,是的,但更多的信息,所以值得.现在读者知道`myInput`可能是null(如果你要修改代码,那就是非常了解),并且知道你已经考虑过它了.或者,如果你坚持它是简短的,`Objects.equals(myInput,"Something")`. (2认同)

SiN*_*SiN 5

那么,我们将整个代码颠倒过来进行更改怎么样?

那些先喜欢自己的常数的人,看到这里会作何感想?

if ( 2 == i) 
Run Code Online (Sandbox Code Playgroud)

在我看来,隐藏 NullPointerException 从来都不是一个好处,而是设计中的一个缺点。

如果您从未预料到会出现 NullPointerException,但却得到了一个,那么您需要让您的应用程序崩溃,跟踪日志并查看为什么会发生这种情况。这可能是一个您完全错过的商业案例:)

如果您选择期望一个 null 参数并且对单独处理它不感兴趣,那么请使用StringUtils.equals(...)等实用程序方法

也就是说,我从不允许我的任何团队成员使用第二种形式,因为它不一致且不可读。