Secara eksplisit memanggil kembali dalam suatu fungsi atau tidak

Beberapa waktu yang lalu saya ditegur oleh Simon Urbanek dari tim inti R (saya percaya) karena merekomendasikan pengguna untuk secara eksplisit menelepon returndi akhir fungsi (komentarnya sudah dihapus):

foo = function() {
  return(value)
}

sebaliknya dia merekomendasikan:

foo = function() {
  value
}

Mungkin dalam situasi seperti ini diperlukan:

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

Komentarnya menjelaskan mengapa tidak menelepon return kecuali sangat dibutuhkan adalah hal yang baik, tetapi ini telah dihapus.

Pertanyaan saya adalah: Mengapa tidak menelepon returnlebih cepat atau lebih baik, dan karenanya lebih disukai?

Pertanyaannya adalah: Mengapa tidak (secara eksplisit) menelepon kembali lebih cepat atau lebih baik, dan karenanya lebih disukai?

Tidak ada pernyataan dalam dokumentasi R yang membuat asumsi seperti itu.
Halaman utama? 'Function' mengatakan:

function( arglist ) expr
return(value)

Apakah lebih cepat tanpa menelepon kembali?

Keduanya function()dan return()merupakan fungsi primitif dan function()itu sendiri mengembalikan nilai yang dievaluasi terakhir bahkan tanpa menyertakan return()fungsi.

Memanggil return()sebagai .Primitive('return')dengan itu nilai terakhir sebagai argumen akan melakukan pekerjaan yang sama tetapi membutuhkan satu panggilan lagi. Sehingga .Primitive('return')panggilan ini (seringkali) tidak perlu dapat menarik sumber daya tambahan. Namun pengukuran sederhana menunjukkan bahwa perbedaan yang dihasilkan sangat kecil dan karenanya tidak dapat menjadi alasan untuk tidak menggunakan pengembalian eksplisit. Plot berikut dibuat dari data yang dipilih dengan cara ini:

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

Gambar di atas mungkin sedikit berbeda pada platform Anda. Berdasarkan data yang diukur, ukuran objek yang dikembalikan tidak menyebabkan perbedaan, jumlah pengulangan (bahkan jika ditingkatkan) membuat perbedaan yang sangat kecil, yang dalam kata nyata dengan data nyata dan algoritma nyata tidak dapat dihitung atau membuat Anda skrip berjalan lebih cepat.

Apakah lebih baik tanpa menelepon kembali?

Return adalah alat yang baik untuk secara jelas merancang "daun" kode di mana rutin harus berakhir, keluar dari fungsi dan mengembalikan nilai.

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

Itu tergantung pada strategi dan gaya pemrograman programmer gaya apa yang dia gunakan, dia tidak dapat menggunakan return () karena tidak diperlukan.

Pemrogram inti R menggunakan kedua pendekatan tersebut yaitu. dengan dan tanpa pengembalian eksplisit () karena dimungkinkan untuk menemukan di sumber fungsi 'basis'.

Berkali-kali hanya return () digunakan (tidak ada argumen) mengembalikan NULL dalam kasus untuk menghentikan fungsi secara kondisional.

Tidak jelas apakah lebih baik atau tidak sebagai pengguna standar atau analis yang menggunakan R tidak dapat melihat perbedaan nyata.

Pendapat saya adalah bahwa pertanyaannya seharusnya: Apakah ada bahaya dalam menggunakan pengembalian eksplisit yang berasal dari implementasi R?

Atau, mungkin lebih baik, pengguna menulis kode fungsi harus selalu bertanya: Apa efek tidak menggunakan pengembalian eksplisit (atau menempatkan objek untuk dikembalikan sebagai daun terakhir dari cabang kode) dalam kode fungsi?

Jika semua orang setuju itu

1. return tidak perlu di akhir fungsi tubuh
2. tidak menggunakan returnsedikit lebih cepat (menurut uji @ Alan, 4,3 mikrodetik versus 5.1)

haruskah kita semua berhenti menggunakan return di akhir fungsi? Saya tentu tidak mau, dan saya ingin menjelaskan alasannya. Saya berharap mendengar jika orang lain membagikan pendapat saya. Dan saya minta maaf jika ini bukan jawaban langsung untuk OP, tetapi lebih seperti komentar subyektif yang panjang.

Masalah utama saya dengan tidak menggunakan returnadalah bahwa, seperti yang ditunjukkan Paul, ada tempat lain di tubuh fungsi di mana Anda mungkin membutuhkannya. Dan jika Anda terpaksa menggunakan returnsuatu tempat di tengah fungsi Anda, mengapa tidak membuat semuanyareturn pernyataan eksplisit? Aku benci menjadi tidak konsisten. Saya juga berpikir bahwa kode membaca lebih baik; seseorang dapat memindai fungsi dan dengan mudah melihat semua titik keluar dan nilai-nilai.

Paulus menggunakan contoh ini:

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

Sayangnya, orang dapat menunjukkan bahwa itu dapat dengan mudah ditulis ulang sebagai:

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

Versi terakhir bahkan sesuai dengan beberapa standar pemrograman kode yang menganjurkan satu pernyataan kembali per fungsi. Saya pikir contoh yang lebih baik adalah:

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

Ini akan jauh lebih sulit untuk ditulis ulang menggunakan pernyataan pengembalian tunggal: itu akan membutuhkan banyak breaks dan sistem variabel boolean yang rumit untuk menyebarkannya. Semua ini untuk mengatakan bahwa aturan pengembalian tunggal tidak cocok dengan R. Jadi jika Anda perlu menggunakannya returndi beberapa tempat di tubuh fungsi Anda, mengapa tidak konsisten dan menggunakannya di mana-mana?

Saya tidak berpikir argumen kecepatan itu valid. Perbedaan 0,8 mikrodetik tidak ada artinya ketika Anda mulai melihat fungsi yang benar-benar melakukan sesuatu. Hal terakhir yang bisa saya lihat adalah kurang mengetik tapi hei, saya tidak malas.

Ini diskusi yang menarik. Saya pikir contoh @ flodel sangat bagus. Namun, saya pikir ini mengilustrasikan poin saya (dan @koshke menyebutkan ini dalam komentar) yang returnmasuk akal ketika Anda menggunakan imperatif alih-alih gaya pengkodean fungsional .

Bukan untuk mempercayai intinya, tetapi saya akan menulis ulang fooseperti ini:

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

Gaya fungsional menghindari perubahan status, seperti menyimpan nilai output. Dalam gaya ini, returntidak pada tempatnya; foolebih mirip fungsi matematika.

Saya setuju dengan @flodel: menggunakan sistem variabel boolean yang rumit di barakan menjadi kurang jelas, dan tidak ada gunanya saat Anda memilikinya return. Apa yang membuatnya barbegitu menerimareturn pernyataan adalah bahwa itu ditulis dalam gaya imperatif. Memang, variabel boolean mewakili perubahan "negara" yang dihindari dengan gaya fungsional.

Sangat sulit untuk menulis ulang bardengan gaya fungsional, karena ini hanya pseudocode, tetapi idenya adalah seperti ini:

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.
}

The whileLoop akan menjadi yang paling sulit untuk menulis ulang, karena dikendalikan oleh negara perubahan kea .

Kehilangan kecepatan yang disebabkan oleh panggilan ke returndiabaikan, tetapi efisiensi yang diperoleh dengan menghindari returndan menulis ulang dengan gaya fungsional sering kali sangat besar. Memberitahu pengguna baru untuk berhenti menggunakan returnmungkin tidak akan membantu, tetapi membimbing mereka ke gaya fungsional akan memberikan hasil.

@ Paul returndiperlukan dalam gaya imperatif karena Anda sering ingin keluar dari fungsi pada titik yang berbeda dalam satu lingkaran. Gaya fungsional tidak menggunakan loop, dan karenanya tidak perlu return. Dalam gaya fungsional murni, panggilan terakhir hampir selalu merupakan nilai pengembalian yang diinginkan.

Dalam Python, fungsi membutuhkan returnpernyataan. Namun, jika Anda memprogram fungsi Anda dalam gaya fungsional, kemungkinan Anda hanya akan memiliki satureturn pernyataan: di akhir fungsi Anda.

Menggunakan contoh dari posting StackOverflow lain, katakanlah kita menginginkan fungsi yang mengembalikan TRUEjika semua nilai dalam suatu diberi xmemiliki panjang ganjil. Kita bisa menggunakan dua gaya:

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

Dalam gaya fungsional, nilai yang akan dikembalikan secara alami jatuh di ujung fungsi. Sekali lagi, ini lebih mirip fungsi matematika.

@GSee Peringatan yang diuraikan dalam ?ifelsepasti menarik, tapi saya tidak berpikir mereka mencoba untuk menghalangi penggunaan fungsi. Bahkan, ifelsememiliki keunggulan fungsi vectorizing secara otomatis. Misalnya, pertimbangkan versi yang sedikit dimodifikasi foo:

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

Fungsi ini berfungsi dengan baik ketika length(a)1. Tetapi jika Anda menulis ulang foodenganifelse

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

Sekarang foobekerja pada ukuran berapa pun a. Bahkan, itu akan berfungsi ketika amatriks. Mengembalikan nilai dengan bentuk yang sama testdengan fitur yang membantu vektorisasi, bukan masalah.

Tampaknya tanpa return()itu lebih cepat ...

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__ _ __ _ __ _ __ _ __ _ ___

Saya melanjutkan ke tolok ukur orang lain (benchmark(fuu(x),foo(x),replications=1e7) ) dan hasilnya terbalik ... Saya akan mencoba di server.

Masalah dengan tidak menempatkan 'kembali' secara eksplisit di akhir adalah bahwa jika seseorang menambahkan pernyataan tambahan di akhir metode, tiba-tiba nilai kembali salah:

foo <- function() {
    dosomething()
}

Ini mengembalikan nilai dosomething().

Sekarang kami datang keesokan harinya dan menambahkan baris baru:

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

Kami ingin kode kami mengembalikan nilai dosomething(), tetapi sebaliknya tidak lagi.

Dengan pengembalian eksplisit, ini menjadi sangat jelas:

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

Kita dapat melihat bahwa ada sesuatu yang aneh dengan kode ini, dan memperbaikinya:

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

Pertanyaan saya adalah: Mengapa tidak menelepon returnlebih cepat

Ini lebih cepat karena returnmerupakan fungsi (primitif) dalam R, yang berarti bahwa menggunakannya dalam kode menimbulkan biaya pemanggilan fungsi. Bandingkan ini dengan sebagian besar bahasa pemrograman lain, di mana returnkata kunci, tetapi bukan panggilan fungsi: ini tidak diterjemahkan ke setiap eksekusi kode runtime.

Yang mengatakan, memanggil fungsi primitif dengan cara ini cukup cepat di R, dan memanggil returnmenimbulkan overhead yang sangat kecil. Ini bukan argumen untuk menghilangkan return.

atau lebih baik, dan karenanya lebih disukai?

Karena tidak ada alasan untuk menggunakannya.

Karena itu berlebihan, dan itu tidak menambahkan redudansi yang berguna .

Untuk menjadi jelas: redundansi dapat kadang-kadang berguna . Tetapi kebanyakan redundansi tidak seperti ini. Alih-alih, itu adalah jenis yang menambahkan kekacauan visual tanpa menambahkan informasi: itu adalah pemrograman yang setara dengan kata pengisi atau bagan sampah ).

Pertimbangkan contoh komentar penjelasan berikut, yang secara universal diakui sebagai redundansi buruk karena komentar tersebut hanya memparafrasekan apa yang sudah diungkapkan oleh kode:

# Add one to the result
result = x + 1

Menggunakan returndalam R jatuh dalam kategori yang sama, karena R adalah bahasa pemrograman fungsional , dan dalam R setiap panggilan fungsi memiliki nilai . Ini adalah properti fundamental dari R. Dan begitu Anda melihat kode R dari perspektif bahwa setiap ekspresi (termasuk setiap panggilan fungsi) memiliki nilai, pertanyaannya kemudian menjadi: "mengapa saya harus menggunakan return?" Perlu ada alasan positif, karena standarnya bukan untuk menggunakannya.

Salah satu alasan positif tersebut adalah untuk memberi sinyal keluar awal dari suatu fungsi, misalnya dalam klausa penjaga :

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

Ini adalah, valid penggunaan non-berlebihan dari return. Namun, klausa penjaga seperti itu jarang di R dibandingkan dengan bahasa lain, dan karena setiap ekspresi memiliki nilai, reguler iftidak memerlukan return:

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

Kami bahkan dapat menulis ulang fseperti ini:

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

... dimana if (cond) exprsama dengan if (cond) expr else NULL.

Akhirnya, saya ingin mencegah tiga keberatan umum:

1. Beberapa orang berpendapat bahwa menggunakan returnmenambahkan kejelasan, karena ini menandakan "fungsi ini mengembalikan nilai". Tetapi seperti yang dijelaskan di atas, setiap fungsi mengembalikan sesuatu dalam R. Berpikir returnsebagai penanda untuk mengembalikan nilai tidak hanya berlebihan, secara aktif menyesatkan .

2. Terkait, Zen Python memiliki pedoman luar biasa yang harus selalu diikuti:

   Eksplisit lebih baik daripada implisit.

   Bagaimana menjatuhkan berlebihan returntidak melanggar ini? Karena nilai pengembalian fungsi dalam bahasa fungsional selalu eksplisit: itu adalah ekspresi terakhirnya. Lagi-lagi ini argumen yang sama tentang explicitness vs redundancy.

   Faktanya, jika Anda ingin saksi mata, gunakan itu untuk menyorot pengecualian pada aturan: tandai fungsi yang tidak mengembalikan nilai bermakna, yang hanya dipanggil untuk efek sampingnya (seperti cat). Kecuali R memiliki penanda yang lebih baik daripada returnuntuk kasus ini: invisible. Sebagai contoh, saya akan menulis

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

3. Tapi bagaimana dengan fungsi yang panjang? Tidakkah mudah kehilangan jejak apa yang dikembalikan?

   Dua jawaban: pertama, tidak juga. Aturannya jelas: ekspresi terakhir dari suatu fungsi adalah nilainya. Tidak ada yang perlu dilacak.

   Tetapi yang lebih penting, masalah dalam fungsi yang panjang bukanlah kurangnya returnpenanda eksplisit . Itu panjang fungsinya . Fungsi panjang hampir (?) Selalu melanggar prinsip tanggung jawab tunggal dan bahkan jika tidak, mereka akan mendapat manfaat dari dipisahkan untuk dibaca.

Saya anggap returnsebagai trik. Sebagai aturan umum, nilai ekspresi terakhir yang dievaluasi dalam suatu fungsi menjadi nilai fungsi - dan pola umum ini ditemukan di banyak tempat. Semua yang berikut ini dievaluasi menjadi 3:

local({
1
2
3
})

eval(expression({
1
2
3
}))

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

Apa returnyang tidak benar-benar mengembalikan nilai (ini dilakukan dengan atau tanpa itu) tetapi "keluar" dari fungsi dengan cara yang tidak teratur. Dalam hal itu, itu adalah setara dengan pernyataan GOTO terdekat dalam R (ada juga break dan next). Saya menggunakan returnsangat jarang dan tidak pernah di akhir fungsi.

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

... ini dapat ditulis ulang karena if(a) a else blebih mudah dibaca dan tidak terlalu keriting. Tidak perlu returnsama sekali di sini. Kasus prototipikal saya tentang penggunaan "pengembalian" akan menjadi seperti ...

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")
   }

Secara umum, kebutuhan akan banyak pengembalian menunjukkan bahwa masalahnya buruk atau terstruktur dengan buruk

<>

return tidak benar-benar membutuhkan fungsi untuk bekerja: Anda dapat menggunakannya untuk keluar dari rangkaian ekspresi yang akan dievaluasi.

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 dapat meningkatkan keterbacaan kode:

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

Argumen redundansi telah banyak muncul di sini. Menurut saya itu bukan alasan yang cukup untuk dihilangkan return(). Redundansi tidak secara otomatis merupakan hal yang buruk. Ketika digunakan secara strategis, redundansi membuat kode lebih jelas dan lebih dapat dikelola.

Pertimbangkan contoh ini: Parameter fungsi sering memiliki nilai default. Jadi, tentukan nilai yang sama dengan standarnya adalah redundan. Kecuali itu membuat jelas perilaku yang saya harapkan. Tidak perlu membuka halaman fungsi untuk mengingatkan diri saya apa defaultnya. Dan tidak perlu khawatir tentang versi masa depan dari fungsi yang mengubah standarnya.

Dengan penalti kinerja yang dapat diabaikan untuk pemanggilan return()(sesuai dengan tolok ukur yang diposting di sini oleh orang lain) itu menjadi gaya daripada benar dan salah. Agar sesuatu menjadi "salah", harus ada kerugian yang jelas, dan tidak ada orang di sini yang telah menunjukkan dengan memuaskan bahwa memasukkan atau menghilangkan return()memiliki kerugian yang konsisten. Tampaknya sangat spesifik kasus dan khusus pengguna.

Jadi di sinilah saya berdiri di sini.

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

Saya tidak nyaman dengan variabel "yatim" seperti pada contoh di atas. Apakah abcdakan menjadi bagian dari pernyataan yang belum selesai saya tulis? Apakah ini merupakan sisa dari sambungan / edit dalam kode saya dan perlu dihapus? Apakah saya secara tidak sengaja menempel / memindahkan sesuatu dari tempat lain?

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

Sebaliknya, contoh kedua ini membuat jelas bagi saya bahwa itu adalah nilai pengembalian yang dimaksudkan, daripada beberapa kode kecelakaan atau tidak lengkap. Bagi saya redundansi ini sama sekali tidak sia-sia.

Tentu saja, begitu fungsi selesai dan bekerja saya bisa menghapus pengembalian. Tetapi menghapus itu sendiri merupakan langkah ekstra yang berlebihan, dan menurut saya lebih berguna daripada termasuk return()di tempat pertama.

Semua yang dikatakan, saya tidak menggunakan return()fungsi satu-liner pendek tanpa nama. Itu membuat sebagian besar dari kode fungsi dan karena itu sebagian besar menyebabkan kekacauan visual yang membuat kode kurang terbaca. Tetapi untuk fungsi yang lebih besar didefinisikan dan dinamai secara resmi, saya menggunakannya dan kemungkinan akan terus demikian.