在Java中，即使没有必要，我也应该对参数和本地使用“ final”吗？

#1 楼

我使用final的方式与您相同。对我来说，它在局部变量和方法参数上看起来是多余的，并且没有传达有用的额外信息。

重要的一点是，努力使我的方法简洁明了，每个方法都执行一项任务。因此，我的局部变量和参数的范围非常有限，并且仅用于单个目的。

此外，如您所知，final不能保证您不能更改（非基本）变量的值/状态。只有这样，您才能在初始化后将引用重新分配给该对象。换句话说，它仅与原始或不可变类型的变量无缝地协同工作。考虑

final String s = "forever";
final int i = 1;
final Map<String, Integer> m = new HashMap<String, Integer>();

s = "never"; // compilation error!
i++; // compilation error!
m.put(s, i); // fine

这意味着在许多情况下，它仍然不能使理解代码内部发生的事情变得更加容易，而误解实际上可能会导致一些细微的错误，很难检测到。

#2 楼

您的Java编程风格和想法很好-不必在那里怀疑自己。


另一方面，我发现它
对locals和
参数的用处不大，通常我避免
将它们标记为最终偶数如果它们
将永远不会被重新分配（当它们需要
在内部类中使用时，明显的例外是
）。


这就是为什么您应该使用final关键字的原因。您声明自己知道永远不会将其重新分配，但是没有人知道。使用final立即消除您的代码歧义。

#3 楼

尽可能使用final / const的优点之一是可以减少代码阅读者的精神负担。
确保读者以后不会更改值/引用。因此，开发人员无需为了理解计算而进行修改。
学习纯函数式编程语言后，我已经改变了主意。知道您可以相信“变量”始终保持其初始值，这真是一种欣慰。

#4 楼

我认为方法参数和局部变量中的final是代码噪声。 Java方法声明可能会很长（尤其是对于泛型而言）-无需再进行声明。

如果正确编写了单元测试，则会选择分配给“有害”的参数，因此它实际上应该永远不是问题。视觉清晰度比避免可能的错误（因为单元测试的覆盖范围不足）更重要。

诸如FindBugs和CheckStyle之类的工具可以配置为在进行分配时破坏构建参数或局部变量，如果您非常关心这些事情。

当然，如果需要将它们定型，例如，因为您正在使用匿名类中的值，那么没问题-这是最简单的最简单的解决方案。除了在参数中添加额外的关键字并由此恕我直言伪装的明显效果外，将final添加到方法参数通常会使方法主体中的代码变得更不易读，这会使代码变得更糟-要变得“好”，代码必须具有尽可能高的可读性和简单性。举一个人为的例子，假设我有一个方法需要不区分大小写。

没有final：

public void doSomething(String input) {
    input = input.toLowerCase();
    // do a few things with input
}

简单。清洁。每个人都知道发生了什么。

现在带有'final'，选项1：

public void doSomething(final String input) {
    final String lowercaseInput = input.toLowerCase();
    // do a few things with lowercaseInput
}

在设置参数final时，编码器将停止添加代码如果不再认为他使用的是原始值，则存在同样的风险，即更深一层的代码可能使用input而不是lowercaseInput，它不应也不能受到保护，因为您不能超出范围（甚至将null分配给input（如果仍然有帮助的话）。

使用'final'，选项2：

public void doSomething(final String input) {
    // do a few things with input.toLowerCase()
}

现在，我们刚刚产生了更多的代码噪声，并引入了必须调用n次toLowerCase()的性能问题。

使用'final'，选项3：

public void doSomething(final String input) {
    doSomethingPrivate(input.toLowerCase());
}

/** @throws IllegalArgumentException if input not all lower case */
private void doSomethingPrivate(final String input) {
    if (!input.equals(input.toLowerCase())) {
        throw new IllegalArgumentException("input not lowercase");
    }
    // do a few things with input
}

谈论代码噪声。这是火车残骸。我们有了一个新方法，一个必需的异常块，因为其他代码可能会错误地调用它。更多的单元测试将涵盖该异常。所有这些都是为了避免一条简单且恕我直言的可取且无害的路线。

还有一个问题是方法的长度不应太长，以至于您不易直观地将其引入并一眼就知道

我认为这是一种很好的做法/样式，如果您将参数赋值，则应在方法的每个早期阶段都进行赋值，最好是在基本输入检查之后的第一行或直接输入，有效地将其替换为整个方法，这在方法内具有一致的效果。读者知道，期望任何分配都是显而易见的（在签名声明附近）并且在一致的位置，这大大减轻了添加final试图避免的问题。实际上，我很少分配参数，但是如果我这样做，我总是将其放在方法的顶部。


还请注意，final实际上并没有像最初看起来那样保护您：

public void foo(final Date date) {
    date.setTime(0); 
    // code that uses date
}

final不能完全保护您，除非参数类型是原始或不可变的。

#5 楼

我让eclipse将final放在每个局部变量之前，因为我认为它使程序更易于阅读。我不使用参数，因为我想使参数列表尽可能短，因此理想情况下它应该放在一行中。