将返回的变量命名为“结果”是一种好习惯吗？[关闭]

调用方法返回的变量名是一个好习惯result吗？

例如：

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

还是应该按类型命名？

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

我曾经在野外看到过这两种情况，如果我需要选择一种原因，是什么原因会使我偏爱前者或后者（或任何更好的名字）？

我主要是在考虑Java。

如果这是一个方法变量，则实际上取决于可读性。

既然您已经在变量声明和方法返回类型中都拥有类型名称，则不妨使用result-它描述了变量的作用。

如果将变量命名为，则交叉阅读会更容易result。这使您的意图明确。

如果我需要一个返回变量（实际上很少发生），那么我总是调用它ret并始终在函数头下方定义它。该函数已经有一个名称，该名称说明了所有返回的内容。

如果我有myFunction我可以命名它的返回变量myFunctionReturnValue说完全一样的东西，只有我不得不说，它明确每一次。由于功能通常应简短，因此无需明确。即使我迷路了，我也可以跳转到声明，并将其放到函数定义的下面。

但是，任何其他没有隐式（如ret或result）或显式（如myFunctionReturnValue或myFunctionResult）状态的名称，即当前函数的返回变量都太通用了。

在第二个示例中，这zorglub是一个糟糕的选择。声明真正告诉我的是，您创建了一个变量，该变量的名称等于名称旁边的类型注释。它与int someInt或一样有用Zorglub z。

在您的第一个示例中，当我查看代码时，我首先看到函数名称，该名称告诉我该函数计算一个Zorglub。当我阅读第二行时，我看到“好，这是zorglub，将要返回，但是显然不能立即返回，因此将其存储在result变量中”（作为补充说明：而不是重新分配值，那么最好将变量声明为final来传达该信息），然后我认为“所以现在让我们看看它返回之前会发生什么”。与第一个示例不同，我不需要真正地阅读任何内容即可知道这是变量，它将被返回，并且如果我想理解它，我想在函数体中跟随。

您可能想阅读Spartan编程，它与您的问题有关。

在第二个示例中，您将结果的类型与它是什么混为一谈。

Zorglub zorglub;

告诉我这是Zorglub，两次。如果我不愿意阅读方法返回类型，那将是三遍。然而，

double variance;

例如，就程序语义而言，它为我提供了有关返回值含义的线索。result取决于方法的大小，它可能比仅调用它更清晰，也可能没有，这是对IMO每个方法的判断调用。

如果你有许多Zorglub在方法的对象玩，你“可能”犯了一个错误，并返回一个错误，或/和你可能会倾向于命名别人zorglub1，zorglub2等

如果您将其命名result，就没有机会犯这样的错误。另外，我发现这是一个好名字；我也看到returnedValue或returnedObject几次，它也清楚，虽然有点冗长。

我个人并不完全适合result用作变量名。足够公平，它告诉我相关值是某些计算的结果-但是，我猜想大约（或超过）程序中使用的变量/字段的90％是正确的。

此外，如其他几个答案所述，它可以用于标记要从方法/函数返回的值。但是，如果我的方法简短，只专注于做一件事，并且始终保持单一的抽象水平，那么我将不会有很多局部变量，并且看到一个方法将返回什么将是微不足道的。

因此，我宁愿让我的方法简短明了，并命名我的变量来表示它们所持有的价值的含义，而不是在封闭方法内部扮演局部角色。但是，（例如，在旧代码中）Zorglub result肯定比容易理解Zorglub zorglub。

我个人使用名称result来表示要从函数/方法返回的值。它明确表明它是要返回的值。按类型命名它似乎没有用，因为同一类型的变量可能不止一个。

有什么不同？它只有两个不同的词会做同样的事情，所以真正的问题是哪个听起来更清晰？

“结果”或“ zorglub”。

我更喜欢使用ZorglubResult入门工具来查看结果返回结果， Zorglub以便更轻松地将其与您可能拥有的其他结果进行比较，并可以看到其结果。

我应该按类型来命名吗？

没有永不。这被称为“系统匈牙利语”，并且使用一种程序的想法已经过时了，该程序可以在需要时随时显示任何变量的类型。

每当需要在代码中命名任何内容时，都应提供描述性，有意义且易读的名称。返回变量的情况是人们倾向于对命名感到自满的一个很好的例子。

如果您有一个明确命名的函数，并且只需要一行代码，则可以完全跳过命名。使您的方法简明扼要，始终是您应该追求的目标。但是，有时确实需要用几行代码来完成一个函数。在这些情况下，始终建议您命名变量以匹配函数的用途。

如果该函数的目的是返回计算或决策算法的结果，那么result该变量是要使用的完全合适的名称，但是如果您的函数从列表中返回一个项目，该怎么办？如果您的函数有其他目的，而与数学或列表无关，该怎么办？在这些情况下，最好为变量提供一个有意义的名称，该名称与创建函数的原因有关。当然，如果需要，您可以简单地使用结果，因为它的名称不太可能与其他名称冲突，但是从可读性的角度来看，更有意义地在上下文中命名变量更有意义。

我喜欢组合它们，显示它的含义以及打算将其返回。

所以在您的示例中，结果为resultZorglub

如果它不是真正的问题，而仅仅是结果（不是resultString）

在某个位置设置返回值，然后使用条件语句跳过可能修改它的所有代码，然后立即执行操作，我看不出太大的区别return，因此我选择直接返回，因此没有result变量。

如果您有一个中间值，可以通过条件代码进行更改，也可以不进行更改，那么它不是结果（尚未），因此，当然不应这样命名。

当我使用C ++工作时，我猜想这可能适用于Java。

例如

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

    //calculation

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

这是按合同设计的，因为确保框应位于方法的末尾。但是回报一定是最后的。我们有一个规则，即返回Result是唯一可以遵循suresure块的规则。

在递归函数中，一步一步地携带结果以进行尾部调用优化通常是有效的。为了向用户表明他不需要提供参数，可以合理地将参数命名为“结果”：

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”，而不是将结果称为“结果”，但是在某些语言中，您可以在调用方法时省略括号，因此max将是对方法本身的递归调用。

通常，我希望使用一个能说明结果的名称。但是，如果已经使用了该名称，则可能使用了多个变量，属性或方法，因为存在一个GUI字段，一个字符串表示形式，一个数字和一个用于数据库的名称，而使用另一个则增加了混淆的可能性。在3到7行的简短方法中，名称的“结果”应该不是问题。

在对象Pascal中，这不是选择。您必须Result在函数代码中的某处为变量赋值。

例：

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

因此对我来说很自然，有一个“结果”（或“雷托尔诺”，因为我用葡萄牙语拼写以避免与语言保留字的名称冲突）变量来接收返回值。

当然，如果它是C语言派生的非常简单的表达式，那么我不会费心声明结果变量-直接返回该表达式。

它不仅是您命名结果的名称（我特别喜欢'r'），而且还包括其用途。例如，如果您将要有一个return变量，那么每个return语句都应该返回它。没有“ return r;” 最后，在整个方法/函数中撒上'return m * x + b;“之类的东西。返回r;”。

结果很好。我一眼就能理解代码，因此变量名就达到了目的。