Question

我们与同事讨论内部任务，例如：

return result = myObject.doSomething();

或

if ( null == (point = field.getPoint()) )

这些是可以接受的还是应该被以下内容取代？为什么？

int result = myObject.doSomething();
return result;

或

Point point = field.getPoint();
if ( null == point)

Answer 1

内部任务更难阅读，更容易错过。在复杂的情况下，它甚至可能被遗漏，并可能导致错误。

EG。如果条件评估阻止为变量赋值：

，这将是一个很难找到的错误

if (i == 2 && null == (point = field.getPoint())) ...

如果i == 2为false，则稍后的点变量将没有值。

Answer 2

if ( null == (point = field.getPoint()) )

优点：

少一行代码

缺点：

不太可读。
不会将point的范围限制在语句及其代码块中。
据我所知，不提供任何性能改进
可能并不总是被执行（当它之前的条件评估为false时。

缺点超过专业4/1，所以我会避免它。

Answer 3

这主要与代码的可读性有关。避免使用内部赋值来使代码可读，因为内部赋值不会得到任何改进

Answer 4

功能 Not Necessarily. 可读性 Definitely Yes

Answer 5

应该避免它们。减少每行标识符/操作的数量将提高可读性并提高内部代码质量。以下是关于该主题的有趣研究：http://dl.acm.org/citation.cfm?id=1390647

如此底线，分裂

return result = myObject.doSomething();

到

result = myObject.doSomething();
return result;

可以让其他人更轻松地理解和使用您的代码。与此同时，如果在整个代码库中分散了几个内部任务，只要它们在上下文中易于理解就不会是世界末日。

Answer 6

嗯，第一个不完全是内部任务，但在第二种情况下...它降低了可读性......但在某些情况下如下，

while ( null == (point = field.getPoint()) );

以这种方式写它是好的

Answer 7

在这两种情况下，第一种形式都难以阅读，并且只要您想要检查调试器中的值，就会想要更改它。我不知道在步骤调试时我经常诅咒“简洁”的代码。

Answer 8

在极少数情况下，内部分配会降低程序的复杂性，例如在if (x != null && y != null && ((c = f(x, y)) > 0) {...}中，并且在复杂条件下执行时，您实际上只需要赋值。

但在大多数情况下，内部任务会降低可读性，很容易被错过。

我认为内部赋值是七十年代C编程语言的第一版本的残余，当编译器没有做任何优化时，优化代码的工作留给了程序员。在那个时候内部分配更快，因为没有必要从变量中再次读取值，但是今天对于快速计算机和优化编译器这一点不再重要。然而，一些C程序员习惯了他们。我认为Sun只是将内部赋值引入Java，因为它们希望与C类似，并使C程序员更容易转换为Java。

Answer 9

始终工作并瞄准代码可读性而非可写性。像a > b ? x : y;这样的东西也是如此可能有很多开发人员在阅读你的第一个代码snipet时没有遇到任何问题，但大部分开发人员都习惯了第二个snipet。

Answer 10

更详细的表单也使得在Eclipse等调试器中更容易理解。我经常拆分单行分配，以便更容易看到中间值。

尽管OP没有直接请求，但是类似的情况是函数调用，因为方法参数可以保存行但是更难调试：

myFunction(funcA(), funcB());

不显示返回类型，更难以单步执行。如果这两个值属于同一类型，那么它也更容易出错。

Answer 11

我发现使用内部任务没有任何伤害。它节省了很少的代码行（虽然我确信它不会改善编译或执行时间或内存）。唯一的缺点是对其他人来说可能看起来很麻烦。

内心任务不好吗？

11 个答案: