参数'foo'不应该被分配 - 有什么危害？ [英] The parameter 'foo' should not be assigned -- what's the harm?
问题描述
比较此方法：
void doStuff(String val) {
if (val == null) {
val = DEFAULT_VALUE;
}
// lots of complex processing on val
}
...到这个方法：
void doStuff(String origVal) {
String val = origVal;
if (val == null) {
val = DEFAULT_VALUE;
}
// lots of complex processing on val
}
对于前一种方法，Eclipse会发出警告不应该为参数赋值val'。为什么？
For the former method, Eclipse emits the warning "The parameter 'val' should not be assigned". Why?
对我而言，前者更清洁。一方面，它不强迫我想出两个 。
To my eye, the former is cleaner. For one thing, it doesn't force me to come up with two good names for val (coming up with one good one is hard enough).
（注意：假设封闭类中没有名为 val 的字段。）
(Note: Assume there is no field named val in the enclosing class.)
推荐答案
在这里看起来并不像任何人在这样做。
It doesn't look like anyone's made the curmudgeon's case here.
我通常不会更改参数，实际上我倾向于标记我的参数 final ，以便明确禁止它。几个原因：
I would generally not mutate parameters, and in fact I tend to mark my parameters final in order to explicitly forbid it. A few reasons:
-
赋值给参数可能会被混淆，试图将其用作输出参数，参考： javapractices.com 和清晰度是一切
Assignment to a parameter could be confused with an attempt to use it as an "output parameter", ref: javapractices.com, and clarity is everything
赞成不变性，而且参数值与其他任何事情一样。原语只是一个相同事物的退化情况，对于不可变变量（通常）更容易理解。 Ref，有效的Java项目13 ，或 javapractices.com
Favor Immutability, and that goes for parameter values as much as anything else. Primitives are just a degenerate case of the same thing, it's (generally) easier to reason about immutable variables. Ref, Effective Java Item 13, or javapractices.com
最后（NPI），轻松使用最终， javapractices.com 。然而丑陋可能是在参数签名中，我相信它倾向于识别出意外的错误，并且它突出了可变变量，这通常应该是异常。大多数代码中的大多数可变变量都有懒惰或者对于性能有一定影响的感觉，当明智地选择，不可变的和有名的中间计算更清晰，更易于阅读和验证，并且可以对性能进行干净的优化没有你的帮助。
And finally (NPI), Use final liberally, javapractices.com. However ugly it may be in parameter signatures, I believe it tends to identify unexpected errors and it highlights mutable variables, which generally should be the exception. Most mutable variables in most code are there either for laziness or a perception that it has some effect on performance, when judiciously chosen, immutable, and well-named intermediate computations are clearer, easier to read and verify, and can be cleanly optimized for performance with no help from you.
我不能在抽象中智能地对你的具体情况说话，但是禁止所有其他事情我可能会有所不同，我宁愿：
I can't speak intelligently to your specific case in the abstract, but barring all the other things I might do differently, I'd favor:
void doStuff(final String origVal)
{
final String valOrDefault = (origVal == null) ? DEFAULT_VALUE : origVal;
//lots of complex processing on valOrDefault
}
甚至（假设你不会在一个只有一个参数的真实方法中处理一个空值，它必须是更复杂的一部分）...另外，一般来说，接受 null 作为一个参数应该被明确记录为这样做，如果只是为了加强假参数应该是例外。在第二种方法中，您甚至可以使用 @NonNull 注释。
or even (assuming you wouldn't cope with a null value in a real method with only one argument, it must be part of something more complex)... Also, in general, methods which accept null as a parameter should be explicitly documented as doing so, if only to reinforce the assumption that null parameters ought to be the exception. In the second method, you might even make use of the @NonNull annotation.
/**
* @param origVal string giving value, possibly null, in which case DEFAULT_VALUE is assigned
*/
void doStuff(final String origVal, ... )
{
final String valOrDefault = (origVal == null) ? DEFAULT_VALUE : origVal;
// similar mucking about to make all the parameters behave, separate from
// actually operating on them...
...
reallyDoStuff(valOrDefault,...);
}
private void reallyDoStuff(final String value, ...)
{
assert (value != null);
// do your complex processing
}
相关问题）在StackOverflow上：在适用于Java ...时使用最终修饰符，方法参数中的最终关键字，您最终确定Java中的局部变量和方法参数。
Related questions (and associated argument) on StackOverflow: "Using final modifier whenever applicable in Java...", "final keyword in method parameters", "Do you final-ize local variables and method parameters in Java".
这篇关于参数'foo'不应该被分配 - 有什么危害？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
