有关代码样式的随机想法

最新推荐文章于 2022-04-19 10:51:42 发布

danpu0978

最新推荐文章于 2022-04-19 10:51:42 发布

阅读量81

点赞数

文章标签：单元测试 java python 人工智能编程语言

本文的某些句子具有讽刺意味。 其他人则要当真。 读者应将它们分开。 从这些句子开始。

Java中的方法应保留多长时间？

我在面试中曾多次问过这个问题。没有最好的答案。有编程风格，不同的风格也不同，很多都可以。我绝对接受有人说方法应该尽可能短，但是我也可以接受20到30行的方法。在30行以上，我会有点勉强。

“当我编写此代码时，只有上帝和我理解。现在只有上帝做到了。”
引用未知的程序员。 XX的最后四分之一。世纪。

最重要的是代码是可读的。当您编写代码时，您就可以理解。至少您认为自己了解要编写的代码。您实际编写的代码可能是一个不同的故事。随之而来的是可读性而不是可写性的重要性。

当重构包含一些长方法的代码并将该方法拆分为许多小方法时，实际上是根据线性代码创建树形结构。您可以创建一些小的方法，然后将实际命令移至其中，而不是一行一行接一行。之后，较小的方法会从更高级别调用。为什么它使代码更具可读性？

首先，因为每个方法都会有一个名称。这就是方法所拥有的，在Java中，我们喜欢使用驼峰式的交谈性名称。

private void pureFactoryServiceImplementationIncomnigDtoInvoker(IncomingDto incomingDto){
  incomingDto.invoke();
}

但是，为什么它比内联代码和使用注释更好呢？

// pure factory service implementation incoming dto invoker
incomingDto.invoke();

可能是因为您必须两次键入pureFactoryServiceImplementationIncomnigDtoInvoker吗？我知道您不会输入两次。您将复制粘贴它或使用一些IDE自动完成功能，因此，将'Incoming'替换为'Incomnig'的类型并不重要。

将代码拆分为小方法时，名称是一种注释形式。

非常类似于我们在使用JUnit 4.0或更高版本的单元测试中所做的工作。旧版本必须从字面test...开始测试方法test...但这不是一个好主意。它是很久以前发现的。（我只是想知道Go何时会到达那里。）如今，Groovy（尤其是spock）使我们可以将带有空格和换行符的整个句子用作单元测试中的方法名称。但是幸运的是，这些方法名称不应键入两次。它们由Junit列出并通过反射调用，因此它们实际上就是它们：文档。

因此，问题仍然是：为什么树结构比线性结构更好？

大概就是我们的大脑运作的方式。我们查看一个方法，然后发现其中有两个方法调用。其中可以有一个简单的分支或循环结构，也许一个嵌套到另一个，但不比这更深。这很简单，而且如果方法名称选择得当（我的意思是用一种很好的，有意义的和有效的交谈方式），那么它们就易于理解，易于阅读。

我们可以使用IDE的导航工具转到方法，然后我们可以集中精力查看所要查看的方法的有限上下文。有一个粗略的规则：

您应该能够在15秒内了解方法的作用。

如果您凝视该方法的时间更长，而您仍然不知道该方法的用途，则意味着它太复杂了。有些人最好理解代码的结构，而其他人则对此感到困难。我属于后一组，因此在查看代码时，很多时候我更喜欢更小，更简单的方法。我拒绝合并代码，或者根据角色和执行的实际任务自行重构代码。与我一起工作的大三学生认为我很严格而且很挑剔。事实是我很慢。代码的复杂性应该与最薄弱的一环兼容：任何团队（包括可以想象的未来20年未来的维护者，直到最终从生产中删除代码）都应该易于理解和维护代码。

很多次查看git历史，我都看到了重构乒乓球。例如方法

Result getFrom(SomeInput someInput){
  Result result = null;
  if( someInput != null ){
    result = someInput.get();
  }
  return result;
}

重构为

Result getFrom(SomeInput someInput){
  final Result result;
  if( someInput == null ){
    result = null;
  }else{
    result = someInput.get();
  }
  return result;
}

然后反过来。

一个较短，而另一个则更具声明性。来回重复重构是否有问题？很有可能是，但不确定。如果只发生几次并且由不同的人执行，则不必担心太多。当代码被重构时，开发人员会觉得代码更加贴在他/她自己身上。更重要的是“这是我的代码”的感觉。即使优秀的开发人员也不怕触摸和修改任何代码。（会发生什么？测试失败？那么呢？测试？什么测试？）请注意，并非所有开发人员都是优秀的开发人员。但是，到底什么是优秀的开发人员？这是相对的。有更好的开发人员，但没有那么优秀。如果您只看到比您更好的优秀开发人员，那么您可能很幸运。或不。