Is it bad to complete the internal tasks?

Question

We discussed this with my colleagues about internal tasks, such as:

return result = myObject.doSomething(); 

or

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

Are they acceptable or should be replaced by the following and why?

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

or

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

Answer 1

An internal task is harder to read and easier to skip. In a difficult state, you can even miss it, and it can cause an error.

Eg. it will be difficult to find an error if evaluating the condition does not allow to assign a value to a variable:

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

If i == 2 is false, then point-to-point will not matter.

Answer 2

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

Pros:

• Another line of code

Minuses:

• Less readable.
• Does not limit the point region to an operator and its code block.
• Doesn't offer any performance improvements as far as I know.
• Perhaps it is not always satisfied (when there is a condition in front of it that evaluates to false).

Cons outperform pros 4/1, so I would avoid that.

Answer 3

This mainly concerns the readability of the code. Avoid internal tasks to make your code readable as you will not get any improvements with internal tasks

Answer 4

Functionally Not Necessarily. For readability Definitely Yes

Answer 5

They should be avoided. Reducing the number of identifiers / operations per line will increase readability and improve the quality of the internal code. Here's an interesting study on the topic: http://dl.acm.org/citation.cfm?id=1390647

So the bottom line separating

 return result = myObject.doSomething(); 

in

 result = myObject.doSomething(); return result; 

make it easier for others to understand and work with your code. At the same time, it would not be the end of the world if a couple of internal tasks were strewn with your entire code base, if they are easily understood in their context.

Answer 6

Well, the first is not quite an internal task, but in the second case ... it reduces readability ... but in some cases, as shown below,

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

It’s good to write like this:

Answer 7

In both cases, the first form is harder to read, and you will want to change it when you want to check the value in the debugger. I don’t know how often I cursed the “compressed” code during step-by-step debugging.

Answer 8

There are very few cases where internal assignments reduce program complexity, for example, in if (x != null && y != null && ((c = f(x, y)) > 0) {...} , and you really only an assignment is needed when it is performed in a complex state.

But in most cases, internal assignments reduce readability and can be easily skipped.

I think that internal assignments are relict for the first versions of the C programming language in the seventies, when compilers did not do any optimizations, and the work on code optimization remained for programmers. At that time, internal assignments were faster because there was no need to read the value from the variable again, but today with fast computers and optimized compilers this point is no longer taken into account. Nevertheless, some C programmers were used for them. I think that Sun introduced internal assignments in Java only because they wanted to be like C and make it easier for C programmers to switch to Java.

Answer 9

Always work and strive for readability. . . The same goes for things like a > b ? x : y; a > b ? x : y; Most developers probably have no problem reading the first code, but most of them are used in the second sniper.

Answer 10

The more complex form also makes tracking easier in a debugger such as Eclipse. I often separate single-line jobs, so intermediate values ​​are more easily visible.

Although not directly requested by the OP, function calls are a similar case, since method arguments can save strings, but it’s more difficult to debug:

 myFunction(funcA(), funcB()); 

does not display return types and is more difficult to execute it. It is also more error prone if two values ​​are of the same type.

Answer 11

I do not find any harm when using internal tasks. It saves a few lines of code (although I'm sure it does not improve compilation, runtime, or memory). The only drawback is that to some this may seem cumbersome.