没有显式地将'return'放在末尾的一个问题是，如果在方法的末尾添加了额外的语句，返回值突然就错了:

foo <- function() {
    dosomething()
}

返回dosomething()的值。

现在我们来到第二天，添加了新的一行:

foo <- function() {
    dosomething()
    dosomething2()
}

我们希望代码返回dosomething()的值，但它不再这样做了。

通过显式返回，这变得非常明显:

foo <- function() {
    return( dosomething() )
    dosomething2()
}

我们可以看到这段代码有些奇怪，并修复它:

foo <- function() {
    dosomething2()
    return( dosomething() )
}

似乎没有return()更快…

library(rbenchmark)
x <- 1
foo <- function(value) {
  return(value)
}
fuu <- function(value) {
  value
}
benchmark(foo(x),fuu(x),replications=1e7)
    test replications elapsed relative user.self sys.self user.child sys.child
1 foo(x)     10000000   51.36 1.185322     51.11     0.11          0         0
2 fuu(x)     10000000   43.33 1.000000     42.97     0.05          0         0

____EDIT __________________

我继续到其他基准(基准(fuu(x)，foo(x)，复制=1e7))，结果是相反的…我在服务器上试试。

返回可以增加代码的可读性:

foo <- function() {
    if (a) return(a)       
    b     
}

我的问题是:为什么不调用返回更快

它更快，因为return是R中的(原语)函数，这意味着在代码中使用它会导致函数调用的代价。与大多数其他编程语言相比，其中return是关键字，而不是函数调用:它不转换为任何运行时代码执行。

也就是说，在R中以这种方式调用原语函数非常快，并且调用return的开销非常小。这不是省略return的理由。

还是更好，因此更可取?

因为没有理由使用它。

因为它是冗余的，它没有增加有用的冗余。

需要明确的是:冗余有时是有用的。但大多数冗余都不是这样的。相反，它是那种在不增加信息的情况下增加视觉混乱的东西:它相当于一个填充词或图表垃圾)。

考虑下面的解释性注释的例子，它被普遍认为是糟糕的冗余，因为注释只是解释了代码已经表达的内容:

# Add one to the result
result = x + 1

在R中使用return也属于同一类别，因为R是一种函数式编程语言，在R中每个函数调用都有一个值。这是R的一个基本属性，一旦你从每个表达式(包括每个函数调用)都有一个值的角度看R代码，问题就变成了:“为什么我要使用return?”需要有一个积极的理由，因为默认是不使用它。

其中一个积极的原因是在一个guard子句中提早退出函数:

f = function (a, b) {
    if (! precondition(a)) return() # same as `return(NULL)`!
    calculation(b)
}

这是一个有效的、非冗余的return用法。然而，与其他语言相比，这样的保护子句在R中很少，而且由于每个表达式都有一个值，正则if不需要return:

sign = function (num) {
    if (num > 0) {
        1
    } else if (num < 0) {
        -1
    } else {
        0
    }
}

我们甚至可以这样重写f:

f = function (a, b) {
    if (precondition(a)) calculation(b)
}

这里if (cond) expr与if (cond) expr else NULL相同。

最后，我想先说三个常见的反对意见:

Some people argue that using return adds clarity, because it signals “this function returns a value”. But as explained above, every function returns something in R. Thinking of return as a marker of returning a value isn’t just redundant, it’s actively misleading. Relatedly, the Zen of Python has a marvellous guideline that should always be followed: Explicit is better than implicit. How does dropping redundant return not violate this? Because the return value of a function in a functional language is always explicit: it’s its last expression. This is again the same argument about explicitness vs redundancy. In fact, if you want explicitness, use it to highlight the exception to the rule: mark functions that don’t return a meaningful value, which are only called for their side-effects (such as cat). Except R has a better marker than return for this case: invisible. For instance, I would write save_results = function (results, file) { # … code that writes the results to a file … invisible() } But what about long functions? Won’t it be easy to lose track of what is being returned? Two answers: first, not really. The rule is clear: the last expression of a function is its value. There’s nothing to keep track of. But more importantly, the problem in long functions isn’t the lack of explicit return markers. It’s the length of the function. Long functions almost (?) always violate the single responsibility principle and even when they don’t they will benefit from being broken apart for readability.

冗余的争论在这里出现了很多。在我看来，这不足以成为省略return()的理由。 冗余并不一定是坏事。如果有策略地使用冗余，可以使代码更清晰、更可维护。

考虑这个例子:函数参数通常有默认值。因此，指定与默认值相同的值是多余的。但这显然是我所期待的行为。不需要打开函数manpage来提醒自己默认值是什么。而且不用担心该函数的未来版本会改变其默认值。

调用return()的性能损失可以忽略不计(根据其他人在这里发布的基准测试)，这取决于样式，而不是对与错。对于“错误”的东西，需要有一个明显的缺点，这里没有人满意地证明包含或省略return()具有一致的缺点。这似乎是非常具体的案例和用户。

这就是我的立场。

function(){
  #do stuff
  ...
  abcd
}

我对上面例子中的“孤儿”变量感到不舒服。abcd会成为我还没写完的声明的一部分吗?它是我的代码中拼接/编辑的残余，需要删除?我是否不小心从其他地方粘贴/移动了一些东西?

function(){
  #do stuff
  ...
  return(abdc)
}

相比之下，第二个示例使我清楚地看到它是一个预期的返回值，而不是一些意外或不完整的代码。对我来说，这种冗余绝对不是无用的。

当然，一旦函数完成并工作，我可以删除返回。但是删除它本身就是一个多余的额外步骤，在我看来，它比首先包含return()更无用。

综上所述，我没有使用return()作为未命名的单行函数。在函数代码中，它占了很大一部分，因此主要导致视觉上的混乱，使代码更不容易读懂。但是对于更大的正式定义和命名的函数，我使用它，并且可能会继续使用。

问题是:为什么不(显式地)更快或更好地调用return，从而更可取?

R文档中没有做这样假设的语句。 主页?'function'说:

function( arglist ) expr
return(value)

不调用return会更快吗?

function()和return()都是基本函数，即使不包括return()函数，function()本身也会返回上一次求值。

将return()作为. primitive ('return')调用，并将最后一个值作为参数将完成相同的工作，但需要多调用一次。因此这个(通常)不必要的. primitive ('return')调用可以获取额外的资源。 然而，简单的测量表明所产生的差异非常小，因此不能成为不使用显式回报的原因。下图是用这种方法选择的数据绘制的:

bench_nor2 <- function(x,repeats) { system.time(rep(
# without explicit return
(function(x) vector(length=x,mode="numeric"))(x)
,repeats)) }

bench_ret2 <- function(x,repeats) { system.time(rep(
# with explicit return
(function(x) return(vector(length=x,mode="numeric")))(x)
,repeats)) }

maxlen <- 1000
reps <- 10000
along <- seq(from=1,to=maxlen,by=5)
ret <- sapply(along,FUN=bench_ret2,repeats=reps)
nor <- sapply(along,FUN=bench_nor2,repeats=reps)
res <- data.frame(N=along,ELAPSED_RET=ret["elapsed",],ELAPSED_NOR=nor["elapsed",])

# res object is then visualized
# R version 2.15

上面的图片在你的平台上可能略有不同。 根据测量的数据，返回对象的大小没有造成任何差异，重复的次数(即使缩放)只产生非常小的差异，这在真实的数据和真实的算法中无法计算或使您的脚本运行得更快。

不调用return会更好吗?

Return是一个很好的工具，可以清晰地设计代码的“叶子”，在这里例程应该结束，跳出函数并返回值。

# here without calling .Primitive('return')
> (function() {10;20;30;40})()
[1] 40
# here with .Primitive('return')
> (function() {10;20;30;40;return(40)})()
[1] 40
# here return terminates flow
> (function() {10;20;return();30;40})()
NULL
> (function() {10;20;return(25);30;40})()
[1] 25
> 

这取决于程序员的策略和编程风格，他使用什么风格，他可以不使用return()，因为它不是必需的。

R核心程序员使用这两种方法。使用或不使用显式return()，因为可以在'base'函数的源中找到。

很多时候只使用return()(无参数)返回NULL来有条件地停止函数。

不清楚它是否更好，因为使用R的标准用户或分析师无法看到真正的区别。

我的观点是这个问题应该是:使用来自R实现的显式返回是否有危险?

或者，更好的是，编写函数代码的用户应该总是问:在函数代码中不使用显式返回(或将要返回的对象作为代码分支的最后一个叶)会有什么影响?