【问题标题】:Java - long one line statements vs multiple lines [closed]Java - 长的一行语句与多行[关闭]
【发布时间】:2016-03-12 19:28:28
【问题描述】:

我的问题很笼统。何时应考虑将语句拆分为多行?

我自己编写代码,从未在团队中工作过。我总是喜欢让我的代码尽可能紧凑。

例如,不要写:

depth = depth - randomNumbers.nextInt(depth) -1;
Expression expA = createRandomExp(depth);
Expression expB = createRandomExp(depth);
SubtractionExpression subExp = new SubtractionExpression(expA,expB);
return subExp;

我只会写:

return new SubtractionExpression(createRandomExp(depth - randomNumbers.nextInt(depth) - 1), createRandomExp(depth - randomNumbers.nextInt(depth) - 1));

我认为的优点是:

  • 代码行数更少。
  • 无需声明变量。

缺点:

  • 可读性较差
  • 有些东西写了多次,比如:randomNumbers.nextInt(depth) -1

行业的标准是什么?写陈述时我应该考虑什么?一些指南可能会有所帮助。

我过来this,但它并没有真正回答我的问题。

【问题讨论】:

  • 我认为避免不必要的变量声明是一个好习惯
  • 为了可读性,我总是更喜欢多个步骤。但这是一个基于意见的答案;)
  • 这个问题真的不是一个好问题。您正在寻求基于意见的答案;这样的东西不属于这里。但是很好;我认为需要平衡。一行 3、5 条语句的真正丑陋之处在于,突然带有行号的异常堆栈跟踪不再那么有用了。而且使用调试器也不那么有趣。
  • 为什么“更少的代码行数”比可读的代码更好?开发软件(在大多数情况下)不是为了减少代码行而进行的竞赛!
  • @Jägermeister 谢谢,甚至没有考虑调试器部分和异常。

标签: java formatting


【解决方案1】:

当其他开发人员需要阅读您的代码时,多行便于阅读,并使用注释行来阐明函数、变量、类等。此外,您可能会离开您工作的公司,并且有人需要改进您的代码或在那里可能是您的代码中的功能障碍,因此在这些原因的情况下,您应该编写多行代码,以使其更易于阅读和理解。 据我所知,不应该有任何标准,但上述原因足以编写多行而不是一行的代码。此外,当您在编写单行代码时遇到编译器错误时,编译器会说“在 X 行中发现错误”,您可能无法理解该行中的错误在哪里。但是,多条线路会缓解这种情况。我建议你写多行而不是单行。

【讨论】:

  • 顺便说一句:普通文本也是如此。视觉垂直间距(称为段落)使消化文本输入变得更加容易......也许你可能会考虑在以后的帖子中考虑;-)
  • 这只是一个介绍,这就是为什么只有一个段落:P
  • 如果我可以用我自己的代表投票 100 次,我会的。只有从未编写过任何有意义的软件,或者有其他人为他们进行调试的人,才会更喜欢单行。我会解雇任何写出这样“聪明代码”的人:)
  • 你甚至在java中使用流吗?
【解决方案2】:

最好不要声明一次性变量。我真的很喜欢方法,当您将“(”括号用作“{”括号时,例如:

return new SubtractionExpression(
    createRandomExp(
        depth - randomNumbers.nextInt(depth) - 1
    ), 
    createRandomExp(
        depth - randomNumbers.nextInt(depth) - 1
    )
 );

【讨论】:

  • “不要重复自己”也是一个好习惯。这正是上面的代码所做的。您将更进一步,并创建一个为您执行 createRandomExp(depth - randomNumbers.nextInt(depth) - 1 的方法。
  • 我认为 create random 不能被提取到变量,它是随机的东西。
  • @ByeBye 它是,randonNumbers 在这种情况下是 SecureRandom 对象。
  • “最好不要声明一次性变量”——您是否实际编写、测试和调试过任何软件?
  • SO 充满了来自开发者的帖子。谁忽略了使用中间温度变量。结果 - 他们无法调试他们的代码,因为他们无法清楚地看到发生了什么。更糟糕的是,他们然后在这里发布他们的垃圾,而不是拆分他们过于复杂的复合表达式,并期望 SO 贡献者为他们解决所有问题:(
猜你喜欢
  • 1970-01-01
  • 2013-03-25
  • 1970-01-01
  • 2018-05-15
  • 2016-11-29
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2018-08-12
相关资源
最近更新 更多