嵌套函数调用 - 什么是最佳实践？

Question

A small thing, but I will be happy to hear what other people think about it.

Which of the 2 code segments below is the best programming practice?

var results = GetResults();

SendResults(results);

OR:

SendResults(GetResults());

I think that the first option is better, but on the other hand option 2 is less code to write (and read). What do you think?

I know it's a very basic question, but still...

Answer 1

I usually go for the first option, because that way I can insert a breakpoint between the invocations of GetResults and SendResults .

It's usually not that big of a deal, if the code is in the middle of a method, but if it's in the form of:

 return Process(GetData());

the return values of both the GetData and the Process calls are not readily visible. Unless we are talking of a framework function that has no side effects and has obvious results (eg int.Parse) I prefer the format:

var data = GetData();
var result = Process(data);
return result;

Answer 2

This

var results = GetResults();
SendResults(results);

is better because it's debuggable... Try putting a breakpoin on SendResults(results) and watch the value of results.

This is so much important that in the next version of Visual Studio , the 2013 they are adding a way to see return value of functions (see for example here )

This new feature allows you to examine the return value of a function when the developer steps over or out of a function during your debugging session. This is especially useful when the returned value is not stored in a local variable. Consider the following nested function example Foo(Bar()); in this example you can now examine the return value(s) from Bar and Foo, when you step over that line.

From a compiled perspective they are normally the same. The only difference at the IL level is that a slot in the stack has some metainformation with the name of the variable ( results ) or is nameless.

Answer 3

In my opinion you have to always strive for clarity, so I'd much rather have:

// notice the type not var (unless it's obvious)
IEnumerable<MyClass> results = GetResults();

SendResults(results);

Answer 4

The first principle when dealing with such issue should be readability (if not dealing with some low-level optimization). In your simple example readability is comparable, but consider code like this:

SendResults(GetResults(Sorter, context.GetCurrentPageInfo(userContext), ...);

Surely, much clearer would be:

var results = GetResults();
var pageInfo = context.GetCurrentPageInfo(userContext);
...
SendResults(results, pageInfo, ...);

As correctly noted in other answers, the more readable version has one more advantage - it is easier to debug, because you can examine all intermediate values.

Answer 5

Personally I prefer the first one, at least when you're debugging you can examine the result of GetResults().

I don't think it's got anything to do with programming practice but more personal style.

Answer 6

var results = GetResults();
SendResults(results);

Is acceptable because it allows for a breakpoint to be used to inspect the value of results . Some programming languages won't optimized this code, and as a result code inspection might issue a warning that the variable results is never modified. C# likely will optimize so there is no problem with.

Code inspectors might issue a warning for inefficient code for the following example;

 var results = GetResults();
 return results;

It depends on the language and I don't think C# has a problem with optimizing that.

Answer 7

If you never need the results anywhere else, my opninion is that the second option is the better. It reads faster and is indeed less code to write. However, it is harder to read, so the programmer who is reading your code should be better and understand things faster.

Answer 8

This is really up to the individual developer. It is quite a subjective thing.

Personally, I prefer the first version because then, if I need to, I can more easily step through the code in the debugger.

At the more fanatical end of proponents of TDD (Test Driven Development) would say that it doesn't matter because you'll never use your debugger if you're doing TDD "right".

I also prefer smaller lines, so if you have a method call that passes in the results of other method calls and the parameter lists start getting excessive it becomes very difficult to read

SendResults(GetResults(arg0, arg1, arg2), SomeOtherMethod(arg3, arg4), arg5);

That begins to get quite difficult to read and keep track of everything.

Ultimately, it is your system and yours to maintain, so what ever style you find easier.

Answer 9

If the results are used in this way, I probably would go for another solution:

class SomeClass
{
    private MyClass _results;
}

private void SendResults()
{
   ... // Implementation which sets _results

Where SendResults gets the results directly from _results and GetResults is not needed (unless it is used by other classes, so it would be:

public MyClass Results { get; private set; }

Answer 10

I know this is pretty old, but with Visual Studio 2017, the argument no longer needs to be based on ease of debugging. There is a new way of handling nested calls. Set your breakpoint on the line with the nested call. When the breakpoint hits, you can step into any level of the nesting using the Step Into Specific context menu (right-click) command. This will show the calls top to bottom from innermost to outermost. This includes lambda functions (such as LINQ predicates).

Answer 11

In my opinion it doesn't matter much, but I have a small preference for the first, because it makes it slightly easier to read, and slightly easier to extend and maintain. Much more important is consistency in my opinion. Do one or the other, but not both.

Answer 12

两者都可以......这只是你的编程风格和经验的问题......但是如果我不得不选择我会选择选项1.更清楚......