Является ли хорошей практикой называть возвращаемую переменную «результатом»? [закрыто]

44

Является ли хорошей практикой вызывать переменную, возвращаемую методом с именем переменной result?

Например:

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

Или я должен назвать его по типу?

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

Я видел как в дикой природе, если мне нужно выбрать один, какие причины могли бы заставить меня предпочесть первое или второе (или любое другое имя)?

Я в основном думаю о Java.

Nicolas Raoul
источник
73
Я также видел, ofTheJediиспользуется для этой цели. Не рекомендация, просто говорю, что видел это. Zorglub ofTheJedi = //...; return ofTheJedi;
7
Я обычно называю это «возвращение» (значение для возврата), но это более или менее то же самое, что и «результат», за который я бы проголосовал.
Зета Два
5
У всех разные ответы, все они похожи, но разные и правильные, вопрос не обязательно субъективен, но ответы есть. Это больше опрос.
ZJR
16
Я бы сказал, что «результат» как переменная - это хорошо, но «вычислять» как функцию - абсолютно нет.
Каз Драгон
2
Ты работаешь со многими бывшими программистами Delphi?
Питер Тернер

Ответы:

48

Если это переменная метода, это действительно зависит от читабельности.

Поскольку у вас уже есть имя типа как в объявлении переменной, так и в типе возвращаемого метода, вы также можете использовать resultего - оно описывает роль переменной.

Одед
источник
40

Перекрестное чтение облегчается, если переменная названа result. Это проясняет ваше намерение.

mouviciel
источник
2
+1 Это главное. Я знаю, что означает результат в любом контексте, просто взглянув на код.
Xeoncross
1
Я согласен, использование типа переменной не поможет вам понять, что вы собираетесь его вернуть. В этих простых примерах легче увидеть возврат без прокрутки или просмотра, но быстрее узнать заранее, каково возвращаемое значение функции. Также важно его инициализировать, как это сделано в примере.
nycynik
17

Если мне нужна возвращаемая переменная (что на самом деле происходит редко), я всегда вызываю ее retи всегда определяю ее прямо под заголовком функции. У функции уже есть имя, которое говорит о том, что она возвращает.

Если бы myFunctionя мог, я мог бы назвать его возвращаемую переменную, myFunctionReturnValueчтобы сказать точно то же самое, только я должен был бы сказать это явно каждый раз. Поскольку функции обычно должны быть короткими, такой явности не требуется. И даже если я потеряю след, я могу перейти к объявлению и попаду прямо под определение функции.

Но любое другое имя, которое неявно (как retили result) или явно (как myFunctionReturnValueили myFunctionResult) не указывает, что текущая переменная возврата функции является слишком общим.

В вашем втором примере zorglubэто ужасный выбор. Все объявления действительно говорят мне, что вы создали переменную, имя которой равно аннотации типа, найденной прямо рядом с именем. Это так же полезно, как int someIntили Zorglub z.

В вашем первом примере, когда я смотрю на код, я сначала вижу имя функции, которая говорит мне, что эта функция вычисляет a Zorglub. Когда я читаю вторую строку, я вижу: «Хорошо, вот zorglub, который будет возвращен, но он, очевидно, не может быть возвращен сразу и, следовательно, хранится в resultпеременной» (как примечание: если вы не собираясь переназначать значение, тогда лучше всего объявить переменную final, чтобы сообщить об этом), а затем я подумаю «так что теперь давайте посмотрим, что произойдет с ним, прежде чем оно будет возвращено». В отличие от первого примера, мне не нужно читать дальше, чтобы узнать, что это переменная, которая будет возвращена и что я хочу следовать в теле функции, если я хочу ее понять.

Возможно, вы захотите прочитать о спартанском программировании , которое скорее связано с вашим вопросом.

оборота back2dos
источник
8
+1 за "зорглуб это ужасный выбор". Нет никакой земной причины иметь имя переменной, в любом контексте, идентичной имени типа (за вычетом начального капитала). Объявление сообщает вам тип переменной - имя вашей переменной после вашего типа не лучше, чем вызов переменных x1, x2, x3 и так далее. Имя любой переменной должно выражать, для чего эта переменная или что она делает. Мое предпочтительное имя для переменной в данном конкретном случае - toReturn - потому что переменная ссылается на возвращаемый объект. На самом деле, многие из моих имен переменных начинаются с "to".
Дауд говорит восстановить Монику
21
@DavidWallace - это слишком сильный абсолют. У меня есть класс под названием Container. Если у меня есть метод, который изменяет количество, я могу сказать, var container = getContainer(id); container.Quantity += 1; что он, безусловно, читается, если контекст метода работает только с одним контейнером, и это все, что он делает. Назвать это theContainerWeAreGoingToAdjustTheQuantityOfпросто смешно.
Скотт Уитлок
4
@ Дэвид, я не согласен. Давайте возьмем ситуацию, когда у вас есть несколько локальных переменных, каждая из которых имеет свой тип (скажем, Пользователь, Менеджер и Отдел). И предположим, что задача состоит в том, чтобы связать пользователя с отделом и командой менеджера. ИМХО, вполне нормально называть этот экземпляр пользователя просто user(в отличие от userToJoinThisDepartmentAndManager? Или какой бы вы выбрали?)
Péter Török
10
Незначительная мелочь: я ненавижу видеть "ret" или "rv" или другие сокращенные варианты result / returnValue. «Результат» не очень длинный, и никому не нужно сохранять символы.
Кристофер Джонсон
2
@KristopherJohnson: «результат» не очень длинный, но он также не означает «возвращаемое значение». Возвращаемые значения не всегда являются результатами вычислений, и наоборот, результаты вычислений не всегда являются возвращаемыми значениями. Я полагаю, вы могли бы назвать ваше возвращаемое значение returnValue, но retэто традиционный, как intи char.
Руах
12

Во втором примере вы связываете тип результата с тем, что он есть .

Zorglub zorglub;

просто говорит мне, что это Zorglub, дважды. Три раза, если я удосужился прочитать метод возврата типа. Тем не мение,

double variance;

например, дает мне представление о том, что означает возвращаемое значение , с точки зрения семантики программы. Это может быть или не быть более понятным, чем просто вызов его result, в зависимости от размера метода - это вызов для каждого метода IMO.

Бесполезный
источник
8

Если вы играете со многими объектами Zorglub в своих методах, вы «можете» ошибиться и вернуть неправильный, или / и у вас может возникнуть соблазн назвать другие zorglub1, zorglub2и т. Д.

Если вы назовете это result, у вас нет шансов совершить такую ​​ошибку. Кроме того, я считаю, что это хорошее имя; Я также видел returnedValueили returnedObjectнесколько раз, это также ясно, хотя и немного долго.

оборота Жалайн
источник
5

Лично мне не совсем удобно использовать resultв качестве имени переменной. Справедливо, это говорит мне о том, что соответствующее значение является результатом некоторых вычислений - однако, я предполагаю, что это верно для (или более) 90% переменных / полей, используемых в программе.

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

Поэтому я предпочитаю, чтобы мои методы были короткими и чистыми, и называли мои переменные, чтобы выразить значение значения, которое они содержат, а не его локальную роль внутри метода включения. Однако (например, в устаревшем коде), Zorglub resultбезусловно, легче понять, чем Zorglub zorglub.

Петер Тёрёк
источник
12
Это не вызывается, resultпотому что это результат некоторых вычислений; это resultвызвано, потому что это - результат этого вычисления. Это также работает как значение IMO, даже если это не самое конкретное возможное значение. Выражение смысла прекрасно, но намерение и идиомы тоже могут быть ценными. В этом случае это немного компромисс.
Supr
@Supr: Какое имя вы бы использовали, чтобы описать результат какого-то другого вычисления, которое будет использоваться только в следующем утверждении или двух (например if (result >= 0) numChars+=result; else break;, и чье значение будет очевидно из рассматриваемого вычисления?) На мой взгляд, значение то, что будет возвращено из этой функции, должно быть вызвано ret, тогда как значение, которое было возвращено из последней вызванной функции, должно быть result. Обратите внимание, что это resultможет быть более значимым, чем более длинное имя, если возвращаемое значение функции может, например, представлять количество или код ошибки.
суперкат
@supercat, я бы назвал его исходя из того, каким было вычисление или для чего предназначено значение. Даже если он используется только в следующих вычислениях, он все же помогает удобочитаемости, если он назван правильно. В вашем примере я понятия не имею, что означает значение resultили что на самом деле делает код на более высоком уровне. Я должен был бы сослаться на то, где это установлено, чтобы видеть, откуда его ценность и каково это. Что-то вроде addedCharsили matchedCharsбудет более прозрачным и поможет раскрыть, что делает код, и не требует умственного манипулирования этим и связанным с ним result = ...:)
Supr
@Supr: проблема в том, что во многих случаях разные диапазоны возвращаемых значений могут означать разные вещи. Например, процедура чтения пакета в буфер указанного размера может вернуть количество байтов, если пакет был получен, или отрицательное число, указывающее, что пакет находился (и остается) в ожидании, что слишком велико для буфера, или действительно большое отрицательное число, чтобы указать на другую ошибку. Сохранение возврата resultи его проверка по этим критериям кажутся более естественными, чем пытаться придумать описательное имя, которое охватывает все из них.
суперкат
@supercat, использование retвместо resultкажется мне нормально. Это немного менее ясно, по моему мнению, потому что это сокращенно и не похоже на существительное, но если оно используется последовательно, то это эквивалентно result.
Supr
1

Я лично использую имя resultдля значения, которое будет возвращено из функции / метода. Это делает явным, что это возвращаемое значение. Называть его по типу не представляется полезным, поскольку может быть несколько переменных одного и того же типа.

Юрай Блахо
источник
Хм, конечно, тот факт, что он скажет «возврат», прежде чем он вернется, является достаточно явным? Вы должны описать, что вы будете делать с ним, теперь «как». Почему бы не назвать это итогом, результатом или чем-то еще, описывающим цель, тогда ваш код будет готов "вернуть итоговое значение" или подобное ...
Дейв
@Dave Не обязательно, особенно если у вас есть несколько объектов одного типа, все из которых должны быть возвращены кандидаты, цель метода - выяснить, какой из них верный.
Энди
@ И я понимаю твою точку зрения, но на самом деле, я не могу представить, чтобы написать такую ​​функцию. Если это и есть причина написания такой функции, похоже, она должна быть разбита на более мелкие и понятные функции.
Дейв
1

Какая разница? это всего лишь два разных слова, которые будут делать то же самое, поэтому реальная проблема в том, какое из них звучит для вас более ясно?

«Результат» или «зорглуб».

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

Berker Yüceer
источник
1

я должен назвать это его типом?

Нет никогда. Это называется Systems Hungarian и тривиально устарело из-за идеи использовать программу, которая может отображать тип любой переменной в любое время, когда вам это нужно.

DeadMG
источник
1

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

Если у вас есть функция с четким именем, и вам нужна только одна строка кода, тогда вы можете полностью пропустить именование. Делать ваши методы короткими и единой целью - это всегда идеал, к которому вы должны стремиться. Тем не менее, иногда вам нужно завершить функцию несколькими строками кода. В этих случаях всегда целесообразно назвать вашу переменную в соответствии с назначением вашей функции.

Если целью функции является возвращение результата вычисления или алгоритма принятия решения, то resultявляется ли абсолютно адекватным имя для вашей переменной, но что делать, если ваша функция возвращает элемент из списка? Что если ваша функция служит какой-то другой цели, которая не имеет ничего общего с математикой или списками? В этих случаях лучше предоставить переменной осмысленное имя, связанное с тем, почему была создана функция. Конечно, вы могли бы просто использовать результат, если хотите, потому что это имя вряд ли будет конфликтовать с чем-то другим, однако с точки зрения читабельности имеет смысл более разумно называть вашу переменную и в контексте.

S.Robins
источник
0

Мне нравится комбинировать их, показывает, что это такое и что оно должно быть возвращено.

так что в вашем примере это будет результат Zorglub

если то, что это на самом деле не имеет значения, то это будет просто результат (не resultString)

KeesDijk
источник
Неплохо, но я думаю, вам придется переименовать вашу переменную, если тип возвращаемого значения изменится. Я полагаю, что с современной IDE это делается в один или два клика.
Джалайн
@Jalayn Да, но если тип был исключен из названия, это изменение, которое вообще не нужно было бы делать. (Если метод достаточно длинный, чтобы простое имя было непонятным, он, вероятно, слишком длинный и должен быть реорганизован.)
Donal Fellows
@DonalFellows Я полностью согласен с вами. Чем меньше изменений вы увидите при обновлении из исходного репозитория, тем лучше.
Джалайн
Хорошо, согласился, что при изменении типа возвращаемого значения вы можете забыть изменить его также в имени переменной, что является проблемой. До сих пор это никогда не было проблемой для меня. Мне все еще нравится показывать двойное намерение в имени, но с меньшим, уже хорошим показом кода намерения это также может быть излишним. Вы, ребята, убедили меня. Если я чувствую необходимость теперь вызывать мои переменные таким образом, я буду рефакторинг до тех пор, пока больше не буду нуждаться в этом. Спасибо
KeesDijk
0

Я не вижу большой разницы между установкой возвращаемого значения в какой-то момент и последующим использованием условных выражений для пропуска всего кода, который может его изменить, и returnнемедленным вводом, поэтому я перехожу к прямому возврату, поэтому resultпеременная отсутствует .

Если у вас есть промежуточное значение, которое может или не может быть изменено условным кодом, тогда оно не является результатом (пока), поэтому его, конечно, не следует называть так.

Саймон Рихтер
источник
0

Когда я работал в C ++, и я думаю, что это применимо к Java, я это делал.

например

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

    //calculation

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

Это проектирование по контракту, так как блок обеспечения должен быть в конце метода. Но возвращение должно быть последним. У нас было правило, что return Result был единственным, что могло следовать за блоком обеспечения.

Ctrl-Alt-Делор
источник
0

В рекурсивной функции часто эффективно переносить результат из шага в шаг, чтобы оптимизировать хвостовой вызов. Чтобы дать пользователю понять, что ему не нужно предоставлять параметр, целесообразно назвать параметр «результатом»:

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

Но чаще я использую «carry» и «sofar», которые я видел в дикой природе и которые в большинстве случаев несут идею еще лучше.

Вторая причина, конечно, если ваша тема предлагает слово «результат», например, если вы делаете арифметическую оценку. Вы можете проанализировать формулу, заменить переменные значениями и в конце вычислить результат.

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

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

Вместо того, чтобы вызывать результат '' result '', мы можем назвать его '' max '', но в некоторых языках вы можете опустить круглые скобки при вызове метода, поэтому max будет рекурсивным вызовом самого метода.

В общем, я бы предпочел имя, которое говорит, каков результат. Но если это имя уже занято, может быть, более чем одной переменной, атрибутом или методом, потому что есть GUI-поле, строковое представление, числовое и одно для базы данных, использование другого увеличивает вероятность путаницы. В коротких методах от 3 до 7 строк, '' результат '' не должен быть проблемой для имени.

неизвестный пользователь
источник
0

В Object Pascal это не выбор. Вы должны присвоить значение Resultпеременной где-то в коде функции.

Пример:

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

Поэтому для меня вполне естественно иметь переменную «Result» (или «Retorno», как я пишу это по-португальски, чтобы избежать конфликта имен с зарезервированными словами языка) для получения возвращаемого значения.

Конечно, если это очень простое выражение в языке, производном от C, я не стану объявлять переменную результата - возвращая выражение напрямую.

Фабрицио Араужо
источник
0

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

КПБ
источник
-1

Результат в порядке. Я могу понять код с первого взгляда, чтобы имя переменной служило цели.

java_mouse
источник