为什么Java使用this.member约定？

Question

我经常看到 Java 代码中使用以下命名约定。

class SomeClass {
    private final String name;

    public SomeClass(final String name) {
        this.name = name;
    }
}

这对我来说似乎有点奇怪。首先，如果您碰巧拼错了方法签名中的变量，它仍然会编译...

class SomeClass {
    private final String name;

    public SomeClass(final String nane) {
        this.name = name;
    }
}

编译正常。可能将 nane 标记为未使用的变量，但赋值（只是变成自赋值）会静默编译。

我发现自己想使用“m”来表示成员变量...

class SomeClass {
    private final String mName;

    public SomeClass(final String name) {
        mName = name;
    }
}

它比 .this 变体短，并且捕获了前面显示的奇怪的拼写错误。

然而，当我将其作为我们新项目的惯例提出时，我的一位同事给了我各种批评，指出“在 Java 中我们不这样做”。

只是好奇为什么？

Answer 1

就我个人而言，我不喜欢使用前缀 - 它使代码更难阅读，IMO。我相信不同的人以不同的方式阅读 - 我最终“在脑海中大声朗读”，而前缀中断了这个过程。显然你可以习惯它，但我宁愿不必。

然而，声称没有人使用这样的前缀是错误的。我曾在使用 Java 的各种不同公司工作过 - 有些使用了前缀，有些则没有。

我还想指出，大多数 IDE 都会向您发出有关拼写错误示例中的无操作分配的警告。例如，在 Eclipse 中我得到：

The assignment to variable name has no effect

如果你经常忽略警告，我会说你有更大的问题:)

Answer 2

我宁愿只在少数需要的地方使用this来消除歧义，而不是在代码中到处拖动前缀。

Answer 3

对成员变量使用特定的前缀是一种匈牙利表示法——技术性的、不好的那种。信息（什么是成员变量，什么不是成员变量）已经在代码中，无需重复。

正如您所注意到的，一个好的 IDE 会警告您有关未使用的变量的信息（并且可能允许您将该警告转变为错误）。语法突出显示还将区分局部变量和成员变量。为什么要提出丑陋的代码约定来完成 IDE 的工作，减少一种非常特定的程序员错误的可能性？

Answer 4

现代 IDE（例如 Eclipse）可以自动为您生成 getter 和 setter，这样就可以避免麻烦。

Answer 5

在第一个示例中，必须使用 this 限定符来显式引用实例成员 name，而不是局部变量（方法参数）name。

当您提到参数名称可能存在拼写错误时，您是对的，这也是一些令人沮丧的错误的根源。过去，我还对字段使用了前缀命名约定，但随着 java 越来越依赖反射，这确实带来了一定程度的痛苦，所以最近我放弃了它。

通过使用单元测试，以及使用在签入之前分析代码并为您标记这些错误的 IDE，可以减少由于拼写错误而出现错误的可能性。

Answer 6

我觉得很奇怪，你的问题做出了这样的假设

Java 使用 this.member 约定

但这绝不是真的，因为不同的人有不同的约定。
在我的代码中有很多 this.member，但这只是因为我的 IDE（netbeans）生成了它，而且我不太关心重写。

Answer 7

this.member 不是约定，但它是必要的，例如，当您必须在方法中显式引用与局部变量同名的实例变量时。

在其他非强制性情况下，您可以省略它，因为它是隐式的，并选择您想要的约定。

Answer 8

实际上，我有一个讲座，我的一位教授在作业中给了我们以下 java 类：

public class Person {
    private String name;
    private int age;

    public Foo(String __name, int __age) {
        name = __name;
        age = __age;
    }

    public String sayHello() {
        return "Hello, my name is " + name + " and I am " + age + " years old";
    }
}

我提到了 Java 编码约定 并善意地询问他我是否可以重构他的代码。基本上 this 是为了编写漂亮的构造函数和设置器。当然，对于所有其他情况，我需要将方法参数重命名为 underunder + 参数名称，甚至更好的 p + 参数名称，正如我经常看到的那样。