约定在传递给方法之前将空值命名为引用？

我的问题更多的是编码惯例和练习 - 但是对内存或性能有什么影响吗？约定在传递给方法之前将空值命名为引用？

我有这样一个方法，它接受SOMETYPE的数据：

public void someMethod(SomeType sm) { 
    //does something 
} 

Practice #1: 
public void callerMethod() { 
    SomeType someName = null; 
    someMethod(someName); 
} 

Practice #2: 
public void callerMethod() { 
    someMethod(null); 
}

不实践＃1内存基准制作任何影响，程序员甚至应该考虑的？并且是“首选做法”？

应该将练习＃2作为“不良练习”避免，因为它没有给出关于通过什么数据为空的任何线索？另外它会在重载方法的情况下产生问题？

来源

2017-05-22 Ajeetkumar

所有'null'值是相同的，它们没有类型。你可以添加像这样的变量来使代码更加自我记录，但它们没有任何区别（除非你有方法重载） –

我会说（完全主观）方法1，而它可以用来消除重载方法之间的歧义，对我来说似乎很特别。这肯定会让我停下来思考“这到底是怎么回事？”几秒钟，当我读它时，而'someMethod（（SomeType）null）'不会。 – biziclop

真正的最佳实践在这里：首先要注意将搭建的方法与null参数放在一起。

为什么不有两个公开方法：期望一个非空对象;并且需要否参数？使你的意图比你的两个建议更清晰。

允许空值总是带有遗漏代码中需要空检查的地方的风险;所以如果你考虑最佳实践：提出干净，精确的界面，使其硬被错误地使用。

而关于性能：只需忘记担心这一点。如果您的方法经常被调用以致JIT决定优化它;它将在运行时进行优化。如果JIT发现这种方法每小时调用一次;因此不会优化它 - 为什么你认为你也需要担心？如果有的话，我们在这里谈论的是纳秒。你需要很多方法调用来使纳秒变得重要...

含义：当然，应该避免彻底愚蠢的性能杀手;但绝大多数情况下，您绝对会在关注的可读性。请记住，premature optimization thing？

来源

2017-05-22 09:26:04 GhostCat

这是拥有两种公共方法的好主意。 – Ajeetkumar

性能和字节码有什么不同？是someMethod（（SomeType）null）;比创建局部变量更好吗？ – Ajeetkumar

在这种情况下，如果您明确拥有两个执行路径（因为您可以调用两个单独的方法），则具有'null'输入特别臭。 – biziclop

练习＃1有点多余，因为它创建了一个不必要的局部变量。

您可以

someMethod((SomeType) null);

更换这种做法在实践＃当someMethod超载2是消除不确定性的唯一好处（即，如果您有多个方法称为someMethod中采用单一引用类型的参数，调用someMethod(null)在某些情况下不会通过编译，因为编译器不知道要调用哪个方法）。

来源

2017-05-22 09:20:57 Eran

只是为了说明一点，铸造VS不必要的局部变量。并没有java编译器优化将使两个代码相同的字节码？ – Ajeetkumar

@Ajeetkumar这是可能的。欢迎您来测试它。但是，在这种情况下，我发现一行代码（如'someMethod（（SomeType）null）'）更具可读性。 – Eran

在此处进行调用，因为您明确提到了超载和传递特定类型的部分......这是我忽略的部分。 – GhostCat

约定在传递给方法之前将空值命名为引用？

回答

相关问题