简单比较还是直接比较的方法描述名？

Question

有时会有非常简单的比较，如 equals、compareTo、... 如下：

//Status is a String, and 
if(status.equals(StatusEnum.ACTIVE.value()) && dateRegister.isAfter(LocalDate.now)){
    //do something
} else {
   //do something
}

但我更喜欢创建一个名称更具描述性的方法，尽管我使用过一次：

private boolean isActive(String status){
   return status.equals(StatusEnum.ACTIVE.value()) && dateRegister.isAfter(LocalDate.now);
}

然后：

if(isActive(status)){
    //do something
} else {
   //do something
}

为这种简单的比较创建一个方法是个好主意还是好做法？

有时我觉得我创造了很多方法来提高可读性，但有些人不太喜欢....

Answer 1

当然，您在这里提出的是更好的风格。您在那里练习的是 Clean Code 的一个重要方面。这实际上是一种很好的做法。

其背后的原因：您的大脑会自动将时间花在 "creating context" 上。这意味着：当您查看源代码时，您会立即开始寻找有助于您理解正在发生的事情的界限。

从这个意义上说，用于此类检查的小辅助方法（带有一个好名字！）可以让您的大脑几乎立即掌握正在发生的事情。

不习惯这种风格的人最初通常会拒绝它。但重点是：当您要求他们阅读此类代码时，他们通常会觉得容易阅读；尽管他们练习不同的风格。他们不喜欢他们看到的东西，但他们阅读它没有问题！

将其与反向实验进行比较：当您开始阅读 "their" 代码时，按照他们的风格……您很快就会发现他们的代码更难阅读。其他人也一样。因为你的大脑必须处理 "less" 输入。情况变得更糟：当人们习惯于 read/write 其他可读性较差的样式时......经常发生的是他们训练大脑 忽略此类结构 。换句话说：他们接受 "bad style" ... 因为他们受过训练 不要看得太近 。说真的，还有什么比这更糟糕的呢？

是的，最后您甚至可能有一些 "more" 代码可以阅读；但它结构如此精美的事实仍然意味着：最终需要更少的努力。

当然，还有副作用：如果您不将此类代码放入实用方法中，那么人们就会开始使用复制和粘贴。因为您可能需要在多个地方进行此检查。这才是真正痛苦的开始。代码重复从来都不是一个好主意；如果可以通过创建更易于阅读的代码来避免这种情况...那么这就是正确的方法。

Answer 2

不分简单复杂。如果有人看你的代码，那么他将无法理解 if 语句正在检查什么，但是当你将它放在函数中并给出适当的名称时，任何人都可以轻松识别 if 语句正在检查状态是否处于活动状态。创建函数使代码简单、干净且易于理解。

Answer 3

是的，这是很好的做法！

你所做的被称为抽象。你转低级的东西

status.equals(StatusEnum.ACTIVE.value() && 
    dateRegister.isAfter(LocalDate.now)

进入更高层次的东西：

isActive(status)

如果我不太了解您的代码，那么在阅读您的第一段代码时我可能会感到困惑。我会像

Ehh... what is this code doing? Why is it checking all this stuff for?

如果我看了你的第二段代码，我就知道你在检查状态是否活跃，更重要的是，隐藏了我不想知道的低级别我.

另一个优点是您输入的代码更少。当你提取某物作为方法时，下次你想做那个“某事”时，只需调用该方法而不是复制那段代码！

但是，执行此操作时要小心。一定要抽象地命名方法，但不要太抽象或太具体。所以这些名字不太管用：

parameterIsEqualToActiveAndDateRegisterIsAfterToday

checkStuff

简单比较还是直接比较的方法描述名？

Method descriptive name for a simple comparison or comparison directly?

java

coding-style