Rõ ràng gọi trả lại trong một chức năng hay không

Cách đây không lâu, tôi đã bị Simon Urbanek khiển trách từ nhóm nòng cốt R (tôi tin) vì đã khuyến nghị người dùng gọi một cách rõ ràng returnkhi kết thúc một chức năng (mặc dù bình luận của anh ta đã bị xóa):

foo = function() {
  return(value)
}

thay vào đó ông đề nghị:

foo = function() {
  value
}

Có lẽ trong một tình huống như thế này, nó được yêu cầu:

foo = function() {
 if(a) {
   return(a)
 } else {
   return(b)
 }
}

Nhận xét của ông làm sáng tỏ lý do tại sao không gọi returntrừ khi thực sự cần thiết là một điều tốt, nhưng điều này đã bị xóa.

Câu hỏi của tôi là: Tại sao không gọi returnnhanh hơn hoặc tốt hơn, và do đó tốt hơn?

Câu hỏi là: Tại sao không (rõ ràng) gọi trở lại nhanh hơn hoặc tốt hơn, và do đó thích hợp hơn?

Không có tuyên bố nào trong tài liệu R đưa ra giả định như vậy.
Trang chính? 'Hàm' nói:

function( arglist ) expr
return(value)

Có nhanh hơn mà không gọi trở lại?

Cả hai function()và return()là các hàm nguyên thủy và function()chính nó trả về giá trị được đánh giá cuối cùng ngay cả khi không bao gồm return()hàm.

Gọi return()như .Primitive('return')với giá trị cuối cùng đó làm đối số sẽ thực hiện cùng một công việc nhưng cần thêm một cuộc gọi. Vì vậy, .Primitive('return')cuộc gọi không cần thiết này (thường) có thể rút thêm tài nguyên. Tuy nhiên, phép đo đơn giản cho thấy sự khác biệt kết quả là rất nhỏ và do đó không thể là lý do cho việc không sử dụng lợi nhuận rõ ràng. Biểu đồ sau được tạo từ dữ liệu được chọn theo cách này:

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

Hình ảnh trên có thể hơi khác nhau trên nền tảng của bạn. Dựa trên dữ liệu đo được, kích thước của đối tượng trả về không gây ra bất kỳ sự khác biệt nào, số lần lặp lại (ngay cả khi được tăng tỷ lệ) chỉ tạo ra một sự khác biệt rất nhỏ, mà trong từ thực với dữ liệu thực và thuật toán thực không thể được tính hoặc làm cho bạn kịch bản chạy nhanh hơn.

Có tốt hơn mà không gọi trở lại?

Return là công cụ tốt để thiết kế rõ ràng "lá" mã nơi thường trình nên kết thúc, nhảy ra khỏi hàm và trả về giá trị.

# 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
> 

Nó phụ thuộc vào chiến lược và phong cách lập trình của lập trình viên, anh ta sử dụng phong cách nào, anh ta không thể sử dụng return () vì nó không bắt buộc.

Lập trình viên lõi R sử dụng cả hai cách tiếp cận tức là. có và không có return return () vì có thể tìm thấy trong các nguồn của các hàm 'cơ sở'.

Nhiều lần chỉ return () được sử dụng (không có đối số) trả về NULL trong các trường hợp để dừng chức năng.

Không rõ liệu nó tốt hơn hay không như người dùng hoặc nhà phân tích tiêu chuẩn sử dụng R không thể thấy sự khác biệt thực sự.

Ý kiến ​​của tôi là câu hỏi nên là: Có bất kỳ nguy hiểm nào trong việc sử dụng lợi nhuận rõ ràng đến từ việc thực hiện R không?

Hoặc, có thể tốt hơn, người dùng viết mã chức năng nên luôn luôn hỏi: Hiệu quả của việc không sử dụng trả về rõ ràng (hoặc đặt đối tượng được trả về làm lá cuối cùng của nhánh mã) trong mã chức năng là gì?

Nếu mọi người đồng ý rằng

1. return không cần thiết ở cuối cơ thể
2. không sử dụng returnnhanh hơn một chút (theo thử nghiệm của @ Alan, 4,3 micro giây so với 5.1)

tất cả chúng ta nên ngừng sử dụng returnở cuối một chức năng? Tôi chắc chắn sẽ không, và tôi muốn giải thích tại sao. Tôi hy vọng được nghe nếu người khác chia sẻ ý kiến ​​của tôi. Và tôi xin lỗi nếu đó không phải là một câu trả lời thẳng thắn cho OP, mà giống như một bình luận chủ quan dài.

Vấn đề chính của tôi khi không sử dụng returnlà, như Paul đã chỉ ra, có những nơi khác trong cơ thể của một chức năng mà bạn có thể cần nó. Và nếu bạn buộc phải sử dụng returnmột nơi nào đó ở giữa hàm của mình, tại sao không làm cho tất cả các returncâu lệnh rõ ràng? Tôi ghét không nhất quán. Ngoài ra tôi nghĩ rằng mã đọc tốt hơn; người ta có thể quét chức năng và dễ dàng nhìn thấy tất cả các điểm và giá trị thoát.

Paul đã sử dụng ví dụ này:

foo = function() {
 if(a) {
   return(a)
 } else {
   return(b)
 }
}

Thật không may, người ta có thể chỉ ra rằng nó có thể dễ dàng được viết lại thành:

foo = function() {
 if(a) {
   output <- a
 } else {
   output <- b
 }
output
}

Phiên bản sau thậm chí còn phù hợp với một số tiêu chuẩn mã hóa lập trình ủng hộ một câu lệnh return cho mỗi hàm. Tôi nghĩ một ví dụ tốt hơn có thể là:

bar <- function() {
   while (a) {
      do_stuff
      for (b) {
         do_stuff
         if (c) return(1)
         for (d) {
            do_stuff
            if (e) return(2)
         }
      }
   }
   return(3)
}

Điều này sẽ khó hơn nhiều để viết lại bằng cách sử dụng một câu lệnh return: nó sẽ cần nhiều breaks và một hệ thống phức tạp của các biến boolean để truyền bá chúng. Tất cả điều này để nói rằng quy tắc hoàn trả duy nhất không chơi tốt với R. Vì vậy, nếu bạn sẽ cần sử dụng returnở một số nơi trên cơ thể chức năng của mình, tại sao không nhất quán và sử dụng nó ở mọi nơi?

Tôi không nghĩ rằng đối số tốc độ là một đối số hợp lệ. Chênh lệch 0,8 micro giây không là gì khi bạn bắt đầu nhìn vào các chức năng thực sự làm gì đó. Điều cuối cùng tôi có thể thấy là nó ít gõ hơn nhưng này, tôi không lười biếng.

Đây là một cuộc thảo luận thú vị. Tôi nghĩ rằng ví dụ của @ flodel là tuyệt vời. Tuy nhiên, tôi nghĩ rằng nó minh họa quan điểm của tôi (và @koshke đề cập đến điều này trong một bình luận) có returný nghĩa khi bạn sử dụng mệnh lệnh thay vì kiểu mã hóa chức năng .

Không tin vào quan điểm, nhưng tôi sẽ viết lại foonhư thế này:

foo = function() ifelse(a,a,b)

Một kiểu chức năng tránh các thay đổi trạng thái, như lưu trữ giá trị của output. Trong phong cách này, returnlà ra khỏi vị trí; footrông giống như một hàm toán học.

Tôi đồng ý với @flodel: sử dụng một hệ thống phức tạp của các biến boolean trong barsẽ ít rõ ràng hơn và vô nghĩa khi bạn có return. Điều làm cho barrất dễ để returntuyên bố là nó được viết theo phong cách bắt buộc. Thật vậy, các biến boolean đại diện cho các thay đổi "trạng thái" được tránh trong một kiểu chức năng.

Thật sự rất khó để viết lại bartheo phong cách chức năng, bởi vì nó chỉ là mã giả, nhưng ý tưởng là như thế này:

e_func <- function() do_stuff
d_func <- function() ifelse(any(sapply(seq(d),e_func)),2,3)
b_func <- function() {
  do_stuff
  ifelse(c,1,sapply(seq(b),d_func))
}

bar <- function () {
   do_stuff
   sapply(seq(a),b_func) # Not exactly correct, but illustrates the idea.
}

Các whilevòng lặp sẽ là khó khăn nhất để viết lại, bởi vì nó được điều khiển bởi những thay đổi trạng thái để a.

Mất tốc độ gây ra bởi một cuộc gọi đến returnlà không đáng kể, nhưng hiệu quả đạt được bằng cách tránh returnvà viết lại theo kiểu chức năng thường là rất lớn. Nói người dùng mới ngừng sử dụng returncó thể sẽ không giúp ích gì, nhưng hướng dẫn họ theo phong cách chức năng sẽ được đền đáp.

@Paul returnlà cần thiết theo kiểu bắt buộc vì bạn thường muốn thoát hàm tại các điểm khác nhau trong một vòng lặp. Một kiểu chức năng không sử dụng các vòng lặp, và do đó không cần return. Trong một phong cách chức năng thuần túy, cuộc gọi cuối cùng hầu như luôn luôn là giá trị trả về mong muốn.

Trong Python, các hàm yêu cầu một returncâu lệnh. Tuy nhiên, nếu bạn lập trình chức năng của mình theo kiểu chức năng, bạn có thể sẽ chỉ có mộtreturn câu lệnh: ở cuối chức năng của bạn.

Sử dụng một ví dụ từ một bài đăng StackOverflow khác, giả sử chúng tôi muốn một hàm trả về TRUEnếu tất cả các giá trị trong một giá trị xcó độ dài lẻ. Chúng tôi có thể sử dụng hai phong cách:

# Procedural / Imperative
allOdd = function(x) {
  for (i in x) if (length(i) %% 2 == 0) return (FALSE)
  return (TRUE)
}

# Functional
allOdd = function(x) 
  all(length(x) %% 2 == 1)

Trong một kiểu chức năng, giá trị được trả về tự nhiên rơi vào cuối của hàm. Một lần nữa, nó trông giống như một hàm toán học.

@GSee Các cảnh báo được nêu trong ?ifelsechắc chắn rất thú vị, nhưng tôi không nghĩ họ đang cố gắng từ chối sử dụng chức năng này. Trong thực tế, ifelsecó lợi thế của các chức năng vector hóa tự động. Ví dụ: hãy xem xét một phiên bản sửa đổi một chút của foo:

foo = function(a) { # Note that it now has an argument
 if(a) {
   return(a)
 } else {
   return(b)
 }
}

Hàm này hoạt động tốt khi length(a)là 1. Nhưng nếu bạn viết lại foobằng mộtifelse

foo = function (a) ifelse(a,a,b)

Bây giờ foohoạt động trên bất kỳ chiều dài của a. Trong thực tế, nó thậm chí sẽ hoạt động khi alà một ma trận. Trả lại một giá trị có hình dạng giống như testmột tính năng giúp vector hóa, không phải là một vấn đề.

Dường như không có return()nó nhanh hơn ...

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

____ CHỈNH SỬA__ _ __ _ __ _ __ _ __ _ ___

Tôi tiến hành điểm chuẩn của người khác ( benchmark(fuu(x),foo(x),replications=1e7)) và kết quả bị đảo ngược ... Tôi sẽ thử trên máy chủ.

Một vấn đề với việc không đặt 'return' một cách rõ ràng vào cuối là nếu một người thêm các câu lệnh bổ sung vào cuối phương thức, đột nhiên giá trị trả về bị sai:

foo <- function() {
    dosomething()
}

Điều này trả về giá trị của dosomething().

Bây giờ chúng tôi đến cùng vào ngày hôm sau và thêm một dòng mới:

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

Chúng tôi muốn mã của chúng tôi trả về giá trị của dosomething(), nhưng thay vào đó, nó không còn nữa.

Với một sự trở lại rõ ràng, điều này trở nên thực sự rõ ràng:

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

Chúng ta có thể thấy rằng có một cái gì đó kỳ lạ về mã này và sửa nó:

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

Câu hỏi của tôi là: Tại sao không gọi returnnhanh hơn

Nó nhanh hơn bởi vì returnlà một hàm (nguyên thủy) trong R, có nghĩa là việc sử dụng nó trong mã sẽ phát sinh chi phí của một cuộc gọi hàm. So sánh điều này với hầu hết các ngôn ngữ lập trình khác, nơi returnlà một từ khóa, nhưng không phải là một hàm gọi: nó không dịch sang bất kỳ thực thi mã thời gian chạy nào.

Điều đó nói rằng, gọi một hàm nguyên thủy theo cách này là khá nhanh trong R và gọi là returnphát sinh chi phí rất nhỏ. Đây không phải là đối số để bỏ qua return.

hoặc tốt hơn, và do đó thích hợp hơn?

Bởi vì không có lý do để sử dụng nó.

Bởi vì nó dư thừa và nó không hữu ích sự dư thừa .

Để được rõ ràng: sự dư thừa có thể đôi khi có ích . Nhưng hầu hết sự dư thừa không phải là loại này. Thay vào đó, nó thuộc loại bổ sung sự lộn xộn thị giác mà không cần thêm thông tin: đó là chương trình tương đương với một từ điền hoặc chartjunk ).

Hãy xem xét ví dụ sau đây về một nhận xét giải thích, được công nhận trên toàn cầu là sự dư thừa xấu bởi vì nhận xét chỉ đơn thuần là diễn giải những gì mã đã thể hiện:

# Add one to the result
result = x + 1

Sử dụng returntrong R thuộc cùng loại, vì R là ngôn ngữ lập trình chức năng và trong R, mỗi lệnh gọi hàm đều có giá trị . Đây là một nền tảng thuộc tính của R. Và một khi bạn thấy mã R từ phối cảnh mà mọi biểu thức (bao gồm mọi lệnh gọi hàm) đều có một giá trị, thì câu hỏi sẽ trở thành: Tại sao tôi nên sử dụng return? Cần phải có một lý do tích cực, vì mặc định là không sử dụng nó.

Một lý do tích cực như vậy là để báo hiệu thoát sớm khỏi một chức năng, nói trong một mệnh đề bảo vệ :

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

Đây là một sử dụng hợp lệ, không dư thừa return. Tuy nhiên, các mệnh đề bảo vệ như vậy rất hiếm trong R so với các ngôn ngữ khác và vì mọi biểu thức đều có một giá trị, nên thông thường ifkhông yêu cầu return:

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

Chúng tôi thậm chí có thể viết lại fnhư thế này:

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

Sầu đâu if (cond) exprcũng giống như if (cond) expr else NULL.

Cuối cùng, tôi muốn kiểm tra ba phản đối phổ biến:

1. Một số người lập luận rằng việc sử dụng returnthêm sự rõ ràng, bởi vì nó báo hiệu cho chức năng này, hàm này trả về giá trị. Nhưng như đã giải thích ở trên, mọi hàm đều trả về một cái gì đó trong R. Nghĩ về returnviệc đánh dấu một giá trị không chỉ là dư thừa, nó chủ động gây hiểu lầm .

2. Liên quan, Zen của Python có một hướng dẫn tuyệt vời cần phải tuân theo:

   Rõ ràng là tốt hơn so với ngầm.

   Làm thế nào để giảm dư thừa returnkhông vi phạm điều này? Bởi vì giá trị trả về của hàm trong ngôn ngữ hàm luôn rõ ràng: đó là biểu thức cuối cùng của nó. Đây lại là một lập luận tương tự về nhân chứng vs. redundancy.

   Trong thực tế, nếu bạn muốn làm chứng, hãy sử dụng nó để làm nổi bật ngoại lệ cho quy tắc: đánh dấu các hàm không trả về giá trị có ý nghĩa, chỉ được gọi cho các tác dụng phụ của chúng (chẳng hạn như cat). Ngoại trừ R có điểm đánh dấu tốt hơn returntrong trường hợp này : invisible. Chẳng hạn, tôi sẽ viết

   save_results = function (results, file) {
       # … code that writes the results to a file …
       invisible()
   }

3. Nhưng những gì về chức năng dài? Sẽ không dễ dàng để mất theo dõi những gì đang được trả lại?

   Hai câu trả lời: thứ nhất, không thực sự. Quy tắc rất rõ ràng: biểu thức cuối cùng của hàm là giá trị của nó. Không có gì để theo dõi.

   Nhưng quan trọng hơn, vấn đề trong các chức năng dài không phải là thiếu các returndấu hiệu rõ ràng . Đó là chiều dài của hàm . Các chức năng dài hầu như (?) Luôn vi phạm nguyên tắc trách nhiệm duy nhất và ngay cả khi chúng không hoạt động, chúng sẽ được hưởng lợi từ việc phân tách để dễ đọc.

Tôi nghĩ về returnmột mẹo. Theo nguyên tắc chung, giá trị của biểu thức cuối cùng được đánh giá trong hàm trở thành giá trị của hàm - và mẫu chung này được tìm thấy ở nhiều nơi. Tất cả các đánh giá sau đây đến 3:

local({
1
2
3
})

eval(expression({
1
2
3
}))

(function() {
1
2
3
})()

Những gì returnkhông thực sự trả về một giá trị (điều này được thực hiện có hoặc không có nó) nhưng "phá vỡ" chức năng một cách bất thường. Theo nghĩa đó, nó là tương đương gần nhất với câu lệnh GOTO trong R (cũng có ngắt và tiếp theo). Tôi sử dụng returnrất hiếm khi và không bao giờ ở cuối một chức năng.

 if(a) {
   return(a)
 } else {
   return(b)
 }

... Điều này có thể được viết lại vì if(a) a else bnó dễ đọc hơn và ít bị uốn cong hơn. Không cần returnở tất cả ở đây. Trường hợp nguyên mẫu của tôi về việc sử dụng "trở lại" sẽ giống như ...

ugly <- function(species, x, y){
   if(length(species)>1) stop("First argument is too long.")
   if(species=="Mickey Mouse") return("You're kidding!")
   ### do some calculations 
   if(grepl("mouse", species)) {
      ## do some more calculations
      if(species=="Dormouse") return(paste0("You're sleeping until", x+y))
      ## do some more calculations
      return(paste0("You're a mouse and will be eating for ", x^y, " more minutes."))
      }
   ## some more ugly conditions
   # ...
   ### finally
   return("The end")
   }

Nói chung, nhu cầu trả lại nhiều gợi ý rằng vấn đề là xấu hoặc có cấu trúc xấu.

<>

return không thực sự cần một chức năng để làm việc: bạn có thể sử dụng nó để thoát ra khỏi một tập hợp các biểu thức được đánh giá.

getout <- TRUE 
# if getout==TRUE then the value of EXP, LOC, and FUN will be "OUTTA HERE"
# .... if getout==FALSE then it will be `3` for all these variables    

EXP <- eval(expression({
   1
   2
   if(getout) return("OUTTA HERE")
   3
   }))

LOC <- local({
   1
   2
   if(getout) return("OUTTA HERE")
   3
   })

FUN <- (function(){
   1
   2
   if(getout) return("OUTTA HERE")
   3
   })()

identical(EXP,LOC)
identical(EXP,FUN)

return có thể tăng khả năng đọc mã:

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

Đối số của sự dư thừa đã đưa ra rất nhiều ở đây. Theo tôi đó không phải là lý do đủ để bỏ quareturn() . Dự phòng không tự động là một điều xấu. Khi được sử dụng một cách chiến lược, sự dư thừa làm cho mã rõ ràng hơn và dễ bảo trì hơn.

Xem xét ví dụ này: Các tham số chức năng thường có giá trị mặc định. Vì vậy, việc chỉ định một giá trị giống như mặc định là dư thừa. Ngoại trừ nó làm rõ ràng hành vi tôi mong đợi. Không cần phải kéo lên trang man chức năng để nhắc nhở bản thân mặc định là gì. Và không phải lo lắng về một phiên bản tương lai của chức năng thay đổi mặc định của nó.

Với một hình phạt hiệu suất không đáng kể để gọi return()(theo điểm chuẩn được đăng bởi những người khác ở đây), nó đi xuống theo phong cách chứ không phải đúng và sai. Đối với một cái gì đó là "sai", cần phải có một nhược điểm rõ ràng và không ai ở đây đã chứng minh thỏa đáng rằng bao gồm hoặc bỏ qua return()có một nhược điểm nhất quán. Có vẻ như trường hợp cụ thể và người dùng cụ thể.

Vì vậy, đây là nơi tôi đứng trên này.

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

Tôi không thoải mái với các biến "mồ côi" như trong ví dụ trên. Được abcdsẽ là một phần của một tuyên bố tôi đã không hoàn thành văn bản? Đây có phải là phần còn lại của một mối nối / chỉnh sửa trong mã của tôi và cần phải xóa không? Tôi đã vô tình dán / di chuyển một cái gì đó từ một nơi khác?

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

Ngược lại, ví dụ thứ hai này cho tôi thấy rõ rằng đó là một giá trị trả về dự định, thay vì một số mã ngẫu nhiên hoặc không đầy đủ. Đối với tôi sự dư thừa này hoàn toàn không vô dụng.

Tất nhiên, một khi chức năng kết thúc và hoạt động tôi có thể loại bỏ trả lại. Nhưng loại bỏ nó tự nó là một bước bổ sung dư thừa, và theo quan điểm của tôi thì vô dụng hơn là bao gồm return()ở nơi đầu tiên.

Tất cả những gì đã nói, tôi không sử dụng return()trong các chức năng một lớp không tên ngắn. Ở đó, nó chiếm một phần lớn mã của hàm và do đó chủ yếu gây ra sự lộn xộn thị giác làm cho mã ít dễ đọc hơn. Nhưng đối với các hàm được định nghĩa và đặt tên chính thức lớn hơn, tôi sử dụng nó và có khả năng sẽ tiếp tục như vậy.