Явно викликає повернення у функцію чи ні

Нещодавно я отримав докір від Саймона Урбанека від основної команди R (я вважаю) за те, що рекомендував користувачу явно зателефонувати returnв кінці функції (проте його коментар видалено):

foo = function() {
  return(value)
}

натомість він рекомендував:

foo = function() {
  value
}

Можливо, у такій ситуації потрібно:

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

Його коментар пролив трохи світла на те, чому б не зателефонувати, returnякщо суворо не потрібно - це добре, але це було видалено.

Моє запитання: Чому не телефонувати returnшвидше чи краще, і, таким чином, краще?

Питання: Чому (явно) виклик не повертається швидше чи краще, і, таким чином, краще?

У документації на R немає жодного твердження, яке б дало таке припущення.
На головній сторінці "функції" написано:

function( arglist ) expr
return(value)

Це швидше, не вимагаючи повернення?

Обидва function()і return()є примітивними функціями, і function()сам повертає останнє оцінене значення навіть без включенняreturn() функції.

Виклик 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 є хорошим інструментом для чіткого проектування "листя" коду, де розпорядок повинен закінчуватися, вискакувати з функції та повертати значення.

# 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 (), оскільки це не потрібно.

Основні програмісти використовують обидва підходи, тобто. з явним поверненням () і без нього, як це можливо знайти в джерелах функцій 'base'.

Багато разів використовується тільки return () (без аргументу), що повертає NULL у випадках, коли умовно зупиняють функцію.

Незрозуміло, краще чи ні, оскільки стандартний користувач чи аналітик, що використовує R, не можуть бачити реальної різниці.

На мою думку, питання повинно бути таким: чи існує якась небезпека використання явного повернення, що випливає з реалізації R?

Або, може бути , краще, написання коду користувача функція завжди повинні запитати: Що таке ефект НЕ використовуючи явний повернення (або розміщення об'єкта повинен бути повернутий в якості останнього листа коду філії) в коді функції?

Якщо всі згодні з цим

1. return не потрібно в кінці тіла функції
2. використання не returnє незначно швидшим (згідно з тестом @ Алана, 4,3 мікросекунди проти 5,1)

чи всі ми повинні припинити використання returnв кінці функції? Я, звичайно, не хочу, і я хотів би пояснити, чому. Я сподіваюся почути, якщо інші люди поділять мою думку. І прошу вибачення, якщо це не пряма відповідь на ОП, а більше, як довгий суб’єктивний коментар.

Моя основна проблема із невдачею returnполягає в тому, що, як зазначив Пол, в тілі функції є інші місця, де вам це може знадобитися. І якщо вас змушують використовувати returnдесь посередині своєї функції, чому б не зробити всі returnзаяви явними? Я ненавиджу непослідовність. Також я думаю, що код читається краще; можна сканувати функцію та легко бачити всі точки виходу та значення.

Пол використав цей приклад:

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

На жаль, можна зазначити, що його можна легко переписати як:

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

Остання версія навіть відповідає деяким стандартам кодування програмування, які виступають за одне твердження повернення на функцію. Я думаю, що кращим прикладом міг бути:

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

Це було б набагато важче переписати, використовуючи єдиний оператор return: breakдля їх поширення знадобиться кілька s та складна система булевих змінних. Все це говорить про те, що правило єдиного повернення не дуже добре відповідає Р. Отже, якщо вам потрібно буде використовувати returnв деяких місцях тіла вашої функції, чому б не бути послідовним і використовувати його скрізь?

Я не думаю, що аргумент швидкості є дійсним. Різниця в 0,8 мікросекунди - це нічого, коли ви починаєте дивитися на функції, які насправді щось роблять. Останнє, що я можу побачити, це те, що вона менш набирає текст, але ей, я не лінуюся.

Це цікава дискусія. Я думаю, що приклад @ flodel є відмінним. Однак я думаю, що це ілюструє мою думку (а @koshke це згадує у коментарі), яка returnмає сенс, коли ви використовуєте імператив замість функціонального стилю кодування .

Щоб не брати участь у цьому, я б переписав fooтак:

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

Функціональний стиль дозволяє уникнути змін стану, як-от зберігання значення output. У цьому стилі returnпоза місцем;fooбільше нагадує математичну функцію.

Я згоден з @flodel: використання складної системи булевих змінних у barбуло б менш зрозумілим і безглуздим, коли у вас є return. Що робить barтак прихильнимreturn тверджень, це те, що вони написані в обов'язковому стилі. Дійсно, булеві змінні являють собою "стан" змін, уникнених у функціональному стилі.

Переписати barу функціональному стилі дуже важко , тому що це просто псевдокод, але ідея приблизно така:

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

whileЦикл буде найбільш важко переписати, бо він знаходиться під контролем змін стану a.

Втрати швидкості, викликані дзвінком return, незначні, однак ефективність, досягнута уникненням returnта перезаписом у функціональному стилі, часто величезна. Скажіть новим користувачам припинити використання, returnймовірно, не допоможе, але наведення їх на функціональний стиль принесе користь.

@Paul returnнеобхідний в імперативному стилі, тому що ви часто хочете вийти з функції в різних точках циклу. Функціональний стиль не використовує циклів, і тому не потребує return. У чисто функціональному стилі, підсумковий виклик майже завжди є бажаним значенням повернення.

У Python функції вимагають returnоператора. Однак якщо ви запрограмували свою функцію у функціональному стилі, ви, швидше за все, матимете лише однуreturn твердження: наприкінці своєї функції.

Використовуючи приклад з іншої публікації StackOverflow, скажімо, що ми хотіли, щоб функція поверталася, TRUEякщо всі значення в заданій xдовжині мали непарну довжину. Ми можемо використовувати два стилі:

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

У функціональному стилі значення, яке повертається, природно падає на кінці функції. Знову ж таки, це більше схоже на математичну функцію.

@GSee Попередження, викладені в ?ifelse, безумовно, цікаві, але я не думаю, що вони намагаються відмовити від використання функції. Фактично, ifelseмає перевагу автоматично векторизуючі функції. Наприклад, розгляньте трохи змінену версію foo:

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

Ця функція прекрасно працює, коли length(a)дорівнює 1. Але якщо ви переписали fooзifelse

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

Зараз fooпрацює на будь-якій довжині a. Насправді це навіть спрацювало б, коли aє матрицею. Повернення значення тієї самої форми, що testі функція, яка допомагає векторизації, не є проблемою.

Здається, що без 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__ _ __ _ __ _ __ _ __ _ ___

Я переходжу до інших бенчмарк ( benchmark(fuu(x),foo(x),replications=1e7)), і результат зворотний ... Я спробую на сервері.

Проблема з тим, що явно не ставити 'return' в кінці, полягає в тому, що якщо в кінці методу додавати додаткові висловлювання, раптом повернене значення неправильне:

foo <- function() {
    dosomething()
}

Це повертає значення dosomething() .

Тепер ми йдемо наступного дня і додаємо новий рядок:

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

Ми хотіли, щоб наш код повернув значення dosomething() , але замість цього він більше не робить.

З явним поверненням це стає дійсно очевидним:

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

Ми можемо побачити, що в цьому коді є щось дивне, і виправити це:

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

Моє запитання: Чому не дзвонять returnшвидше

Це швидше, тому що returnце (примітивна) функція в R, що означає, що використання її в коді несе вартість виклику функції. Порівняйте це з більшістю інших мов програмування, деreturn це ключове слово, але не виклик функції: це не перекладається на будь-яке виконання коду виконання.

Однак це означає, що виклик примітивної функції таким чином досить швидкий в R, а виклик returnнесе незначні накладні витрати. Це не аргумент для пропущення return.

чи краще, і таким чином кращим?

Тому що немає підстав для цього використовувати його.

Тому що це зайве і не додає корисного надмірності.

Щоб було зрозуміло: надмірність іноді може бути корисною . Але більшість надмірностей не такого роду. Натомість він має таку форму, яка додає візуального безладу без додавання інформації: це програмний еквівалент слова наповнювача або charterjunk ).

Розглянемо наступний приклад пояснювального коментаря, який загальновизнаний як погана надмірність, оскільки коментар лише перефразовує те, що вже виражається в коді:

# Add one to the result
result = x + 1

Використання returnв R належить до тієї ж категорії, оскільки R - функціональна мова програмування , а в R кожен виклик функції має значення . Це фундаментальне властивість R. І як тільки ви бачите R код з точки зору , що кожен вираз ( в тому числі кожного виклику функції) має значення, тоді виникає питання: «чому повинен я використовувати return?» Потрібно мати позитивну причину, оскільки за замовчуванням не використовувати його.

Однією з таких позитивних причин є подання сигналу про ранній вихід із функції, скажімо, у захисному пункті :

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 .

Нарешті, я хотів би запобігти трьом загальним запереченням:

1. Деякі люди стверджують, що використання returnдодає ясність, оскільки це сигналізує "ця функція повертає значення". Але як пояснено вище, кожна функція повертає щось у Р. Мислення returnяк маркера повернення значення не просто зайве, воно активно вводить в оману .

2. Так само, Дзен Пітона є чудовим керівництвом, якого слід завжди дотримуватися:

   Явне краще, ніж неявне.

   Як відкидання зайвого returnне порушує цього? Оскільки повернене значення функції у функціональній мові завжди явне: це останнє вираження. Це знову той самий аргумент щодо явності vs надмірності.

   Насправді, якщо ви хочете виразності, використовуйте його, щоб виділити виняток із правила: позначте функції, які не повертають значущого значення, які викликаються лише за їх побічними ефектами (такими як cat). За винятком R має кращий маркер , ніж returnдля цього випадку: invisible. Наприклад, я писав би

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

3. А як щодо довгих функцій? Чи не буде легко втратити слідку за поверненням?

   Дві відповіді: по-перше, не дуже. Правило зрозуміле: останній вираз функції є її значення. Немає чого слідкувати.

   Але ще важливіше, що проблема довгих функцій - не відсутність явних returnмаркерів. Це тривалість функції . Довгі функції майже (?) Завжди порушують принцип єдиної відповідальності і навіть тоді, коли вони цього не роблять, вони виграють від розбиття за читабельність.

Я думаю про returnтрюк. Як правило, значення останнього вираження, оцінене у функції, стає значенням функції - і ця загальна закономірність зустрічається у багатьох місцях. Усі наведені нижче оцінюють до 3:

local({
1
2
3
})

eval(expression({
1
2
3
}))

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

Що returnнасправді - це не дійсне повернення значення (це робиться з ним або без нього), а "виривання" функції нерегулярним чином. У цьому сенсі це найближчий еквівалент висловлювання GOTO в R (є також перерва і наступний). Я використовую returnдуже рідко і ніколи в кінці функції.

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

... це можна переписати, if(a) a else bщо набагато краще читається і менш кучеряво-дурчасте. returnТут зовсім не потрібно . Мій прототипний випадок використання "повернення" був би чимось на зразок ...

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

Як правило, потреба у багатьох поверненнях говорить про те, що проблема або некрасива, або погано структурована.g

<>

return насправді не потрібна функція для роботи: ви можете використовувати її для виривання з набору виразів, що підлягають оцінці.

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 може збільшити читабельність коду:

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

Тут аргументація надмірності виникла чимало. На мою думку, це недостатньо підстав для того, щоб пропустити return(). Надлишок не є автоматично поганою справою. При стратегічному використанні надмірність робить код більш чітким та обслуговуваним.

Розглянемо цей приклад: параметри функції часто мають значення за замовчуванням. Отже, вказати значення, яке є таким самим, як і за замовчуванням, є зайвим. За винятком того, що це очевидно та поведінка, яку я очікую. Не потрібно підтягувати сторінку функції, щоб нагадувати собі, що таке значення за замовчуванням. І не хвилюйтеся про майбутню версію функції, яка змінює її за замовчуванням.

З мізерним штрафом за виклик за дзвінки return()(згідно з орієнтирами, розміщеними тут іншими), це зводиться до стилю, а не правильно та неправильно. Для того, щоб щось було «неправильно», має бути чіткий недолік, і тут ніхто не задовільно продемонстрував, що включення чи пропущення return()має постійний недолік. Це здається дуже конкретним та конкретним для користувачів.

Тож ось де я стою на цьому.

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

Мені незручно зі змінними "сирота", як у прикладі вище. Чи abcdбуде частиною заяви, яку я не закінчив писати? Це залишок сплайса / редагування в моєму коді і його потрібно видалити? Чи випадково я щось вставив / перемістив з іншого місця?

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

На противагу цьому, цей другий приклад дає мені зрозуміти, що це призначене повернене значення, а не якась аварія чи неповний код. Для мене ця надмірність абсолютно не марна.

Звичайно, як тільки функція закінчена і я працюю, я міг би видалити повернення. Але його видалення - саме по собі зайвий додатковий крок, і на мій погляд, марніше, ніж return()в першу чергу.

Все, що сказано, я не використовую return()в коротких неназваних однолінійних функціях. Там він складає велику частину коду функції, а тому здебільшого спричиняє зорове скупчення, що робить код менш розбірливим. Але для великих формально визначених та названих функцій я використовую її і, ймовірно, продовжуватиму це робити.