在Java中,有一种惯例,将每个变量(局部变量或类)声明为final参数(如果它们确实是final的话)。
虽然这会使代码更加冗长,但这有助于容易阅读/掌握代码,也可以防止错误,因为意图被清晰地标记出来。
你对此有何看法?
在Java中,有一种惯例,将每个变量(局部变量或类)声明为final参数(如果它们确实是final的话)。
虽然这会使代码更加冗长,但这有助于容易阅读/掌握代码,也可以防止错误,因为意图被清晰地标记出来。
你对此有何看法?
当前回答
我很少在方法或类上使用final,因为我喜欢允许人们重写它们。
否则,我只使用finally如果它是一个公共/私有静态最终类型SOME_CONSTANT;
其他回答
强烈鼓励使用final作为常量。但是,我不会将它用于方法或类(或者至少考虑一下),因为它使测试更加困难,如果不是不可能的话。如果一定要让一个类或方法成为final,请确保这个类实现了一些接口,这样就可以让一个模拟实现相同的接口。
我从不在局部变量上使用它们,没有什么意义。即使您不认为变量应该被重新赋值,这对于下一个改变代码的人来说也没有什么区别,而且由于代码正在被更改,任何使其最终的原始目的都可能不再有效。如果只是为了清晰,我认为它失败了,因为冗长的负面影响。
对于成员变量也是如此,因为它们提供的好处很少,除了常量的情况。
它也与不可变无关,因为不可变的最好指标是它被这样记录并且/或没有可以改变对象的方法(这与使类为final是保证它是不可变的唯一方法)。
但是,嘿,这只是我的观点:-)
我已经编写了一段时间的代码,并尽可能使用final。这样做了一段时间后(对于变量、方法参数和类属性),我可以说90%(或更多)的变量实际上是最终的。我认为在你不想修改变量的时候不修改变量的好处(我以前看到过,有时这很痛苦)是为了在你的代码中额外的输入和额外的“final”关键字。
也就是说,如果我要设计一种语言,我将使每个变量都是final,除非被其他一些关键字修改。
对于类和方法,我不太使用final。这是一个或多或少复杂的设计选择,除非您的类是一个实用程序类(在这种情况下,您应该只有一个私有构造函数)。
我也使用Collections.unmodifiable…在我需要的时候创建不可修改的列表
我将它用于方法内部和外部的常量。
我有时只将它用于方法,因为我不知道子类是否不想覆盖给定的方法(无论出于什么原因)。
至于类,我只对一些基础类使用了final类。
IntelliJ IDEA会在函数参数被写入函数内部时发出警告。我已经停止使用final作为函数参数了。我在java运行库中也没有看到它们。
我从来没有遇到过在变量上有最后一个关键字就能阻止我犯错误的情况,所以目前我认为这是一种巨大的浪费时间。
除非有真正的理由这样做(比如你想要明确指出变量是final的),否则我宁愿不这样做,因为我发现这样做会使代码的可读性降低。
但是,如果您没有发现它会使代码更难阅读或更长时间地编写,那么无论如何都可以使用它。
编辑:作为一个澄清(并试图赢回反对票),我不是说不要将常量标记为最终值,我是说不要做这样的事情:
public String doSomething() {
final String first = someReallyComplicatedExpressionToGetTheString();
final String second = anotherReallyComplicatedExpressionToGetAnother();
return first+second;
}
在我看来,这只是让代码更难阅读。
同样值得记住的是,所有final的作用都是防止你重新分配变量,它并没有使它成为不可变或类似的东西。