Чи є хорошою практикою називати повернуту змінну "результатом"? [зачинено]

Чи є гарною практикою викликати змінну, яку метод повертає зі змінною назвою result?

Наприклад:

public Zorglub calculate() {
    Zorglub result = [...]
    [...]
    return result;
}

Або я повинен назвати його за його типом?

public Zorglub calculate() {
    Zorglub zorglub = [...]
    [...]
    return zorglub;
}

Я бачив і те, і інше в дикій природі, якщо мені потрібно вибрати одну, з яких причин могло б змусити мене віддавати перевагу колишньому чи останньому (або будь-якому кращому імені)?

В основному я думаю про Яву.

Якщо це змінна методика, це дійсно залежить від читабельності.

Бачачи, як у вас вже є ім'я типу як в декларації змінної, так і в типі повернення методу, ви також можете використовувати result- це опис ролі змінної.

Перехресне читання полегшується, якщо змінна названа result. Це дає зрозуміти ваш намір.

Якщо мені потрібна змінна повернення (що насправді трапляється рідко), я завжди її називаю retі завжди визначаю її прямо під головкою функції. У функції вже є назва, яка говорить про те, що вона повертає.

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

Але будь-яке інше ім’я, яке не імпліцитно (як retабо result) або явно (як myFunctionReturnValueабо myFunctionResult), що це поточна змінна функція повернення занадто загальна.

У вашому другому прикладі zorglub- жахливий вибір. Все декларація насправді говорить мені про те, що ви створили змінну, назва якої дорівнює анотації типу, знайденій прямо біля імені. Це приблизно так корисно, як int someIntі Zorglub z.

У вашому першому прикладі, коли я дивлюся на код, я вперше бачу ім'я функції, яке говорить мені, що ця функція обчислює a Zorglub. Коли я читаю другий рядок, я бачу "добре, ось zorglub, який буде повернутий, але він, очевидно, не може бути повернутий відразу і тому зберігається у resultзмінній" (як побічна примітка: Якщо ви не збираючись перепризначати значення, тоді найкраще оголосити змінну остаточною, щоб повідомити про це), і тоді я думаю, "тому тепер давайте подивимося, що з нею відбувається, перш ніж воно буде повернене". На відміну від першого прикладу, мені не потрібно насправді читати далі, ніж це, щоб знати, що це змінна, яку потрібно повернути і що я хочу слідувати в тілі функції, якщо я хочу це зрозуміти.

Можливо, ви захочете прочитати про спартанське програмування , яке скоріше пов'язане з вашим питанням.

У другому прикладі ви поєднуєте тип результату з тим, що він є .

Zorglub zorglub;

просто каже, що це Zorglub, двічі. Три рази, якщо я переймаюся читати метод повернення типу. Однак,

double variance;

наприклад, дає мені поняття про те, що означає повернене значення з точки зору семантики програми. Це може бути або не бути яснішим, ніж просто викликати його result, залежно від розміру методу - це виклик судження для кожного методу ІМО.

Якщо ви граєте з багатьма об'єктами Zorglub в своїх методах, ви «могли б» зробити помилку і повернути неправильний, або / і ви могли б виникнути спокуса назвати іншим zorglub1, zorglub2і т.д.

Якщо ви його resultназвете, у вас немає шансу зробити подібну помилку. Плюс, я вважаю, що це гарне ім’я; Я також бачив returnedValueабо returnedObjectкілька разів, також зрозуміло, хоча і трохи тривалий.

Мені особисто не зовсім зручно використовувати resultяк ім'я змінної. Досить справедливо, це говорить мені, що пов'язане значення є результатом деяких обчислень - однак, я думаю, це вірно приблизно (або більше) 90% змінних / полів, що використовуються в програмі.

Більше того, як відзначено кілька інших відповідей, воно може бути використане для позначення значення, яке потрібно повернути з методу / функції. Однак, якщо я буду тримати свої методи короткими, зосередженими на тому, щоб робити одне лише і послідовно залишатися на одному рівні абстракції, у мене не буде багато локальних змінних, і буде банально бачити, який метод повертається.

Тому я вважаю за краще тримати свої методи короткими та чистими та називати свої змінні, щоб висловити значення значення, яке вони зберігають, а не його локальну роль у методі, що вкладається . Однак (наприклад, у застарілому коді), Zorglub resultбезумовно, можна зрозуміти простіше, ніж Zorglub zorglub.

Я особисто використовую ім'я resultдля значення, яке повертається з функції / методу. Це робить явним, що це значення, яке потрібно повернути. Назвати його за типом не здається корисним, оскільки може бути більше однієї змінної того ж типу.

Яка різниця? лише два різні слова, які зроблять те ж саме, справжньою проблемою є те, яке з них вам здається більш зрозумілим?

"Результат" або "zorglub".

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

я повинен назвати це за його типом?

Ні ніколи. Це називається Система Угорська і тривіально застаріла ідеєю використання програми, яка може відображати тип будь-якої змінної в будь-який час, коли вона вам потрібна.

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

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

Якщо метою функції є повернення результату обчислення або алгоритму прийняття рішення, то resultце цілком адекватне ім'я для використання вашої змінної, але що робити, якщо ваша функція повертає елемент зі списку? Що робити, якщо ваша функція служить якійсь іншій цілі, яка не має нічого спільного з математикою чи списками? У цих випадках краще надати змінній змістовне ім’я, яке стосується того, чому функція була створена. Звичайно, ви можете просто використовувати результат, якщо хочете, тому що це ім'я, яке, швидше за все, не зіткнеться ні з чим іншим, однак з точки зору читабельності має сенс називати свою змінну більш змістовно та в контексті.

Мені подобається поєднувати їх, показує, що це таке, і що воно призначене повернути.

тож у вашому прикладі це буде результатZorglub

якщо те, що це насправді не має значення, це був би просто результат (not resultString)

Я не бачу великої різниці між встановленням значення повернення на якийсь момент і потім використанням умовних умов, щоб пропустити весь код, який міг би його змінити, та returning, одразу, тому я переходжу до прямого повернення, отже, resultзмінної немає .

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

Коли я працював на C ++ і, мабуть, це може застосовуватися і в Java.

напр

int Width() const
{
    Requires(....);
    Requires(....);

    //calculation

    Ensures(...);
    Ensures(...);
    return Result;
}

Це дизайн за контрактом, оскільки блок забезпечення повинен бути в кінці методу. Але повернення має бути останнім. У нас було правило, що результат Result - це єдине, що може слідувати блоку забезпечення.

У рекурсивній функції часто ефективно переносити результат від кроку до кроку, щоб зробити оптимізацію хвостового дзвінка. Щоб повідомити користувачеві, що йому не потрібно вводити параметр, можна доцільно назвати параметр "результат":

def removeOccurence [A] (slice: Seq[A], original: Seq[A]) = {
  @scala.annotation.tailrec
  def remove (leftOriginal: Seq[A], result: Seq[A]) : Seq[A] =
    trimStart (slice, leftOriginal) match {
      case (h :: tail) => remove (tail, h +: result)
      case (Nil)       => result.reverse
    }
    remove (original, Nil)
}

Але найчастіше я використовую «переносити» та «диван», які я бачив у дикій природі, і які в більшості випадків несуть ідею ще трохи краще.

Друга причина, звичайно, якщо ваша тема пропонує слово "результат", наприклад, якщо ви робите арифметичну оцінку. Ви можете проаналізувати формулу, замінити змінні значеннями та в кінці підрахувати результат.

Третя причина вже була заявлена, але у мене є невелике відхилення: ви пишете метод, який виконує якусь роботу, скажімо, він оцінює форму '' max ''.

def max = {
  val result = somethingElseToDo
  if (foo) result else default 
}

Замість того, щоб називати результат "результатом", ми могли б назвати його "макс", але в деяких мовах ви можете опустити дужки при виклику методу, тому max був би рекурсивним викликом до самого методу.

Взагалі я вважаю за краще ім'я, яке говорить про те, який результат. Але якщо це ім’я вже прийнято, можливо, за допомогою декількох змінних, attribut або методу, оскільки є поле GUI, подання рядків, числове та одне для бази даних, використовуючи інше, збільшується ймовірність плутанини. У коротких методах від 3 до 7 рядків "результат" не повинен бути проблемою для імені.

У Object Pascal це не вибір. Вам слід присвоїти значення Resultзмінній десь у коді функції.

Приклад:

function AddIntegers( A,B: Integer): Integer;
begin
  Result := A + B; 
end; 

Тож для мене цілком природно мати змінну "Результат" (або "Retorno", оскільки я пишу це португальською мовою, щоб уникнути конфлікту імен із зарезервованими мовами мови), щоб отримати повернене значення.

Звертаючись до уваги, якщо це дуже простий вираз мовою, що походить з С, я не буду намагатися оголошувати змінну результату - повернення виразу безпосередньо.

це не тільки те, що ви називаєте результат (я конкретно до 'r'), але і те, як його використовувати. наприклад, якщо у вас буде змінна повернення, то кожне твердження про повернення має повертати її. не мають 'return r;' наприкінці, але розпорошіть такі речі, як 'return m * x + b; "упродовж усього методу / функції. використовуйте" r = m * x + b; повернути r; "замість цього.

результат прекрасний. Я в змозі зрозуміти код з першого погляду, тому ім'я змінної послужило цілі.