热门标签 | HotTags
当前位置:  开发笔记 > 编程语言 > 正文

Java编程规范:局部变量使用与方法调用重复性分析

在Java编程中,为了提高代码的可读性和执行效率,建议优先使用局部变量来存储方法的返回值,而不是多次调用同一个方法。这样不仅可以减少方法调用的开销,还能避免潜在的性能问题。此外,使用局部变量还可以增强代码的可维护性和调试便利性。

I prefer to use local variables rather than multiple calls to the same method.

我更喜欢使用局部变量,而不是多次调用同一个方法。

/*
 * I prefer this
 */
Vehicle vehicle = person.getVehicle()
if (vehicle instanceof Car) {
   Car car = (Car) vehicle;
   car.openSunroof();
} else if (vehicle instanceof Bike) {
   Bike bike = (Bike) vehicle;
   bike.foldKickstand();
}
/*
 * Rather than this
 */
if (person.getVehicle() instanceof Car) {
   Car car = (Car) person.getVehicle();
   car.openSunroof();
} else if (person.getVehicle() instanceof Bike) {
   Bike bike = (Bike) person.getVehicle();
   bike.foldKickstand();
}
  • I believe that the first way is going to perform a tiny bit faster
  • 我相信第一种方法会更快一点。
  • I think the second way violates the DRY principle
  • 我认为第二种方法违反了干原则
  • I find the first way more readable and easier to debug (... OK negligible because I could step over)
  • 我发现第一种方法可读性更好,而且更容易调试(……)可以忽略,因为我可以跨过去)
  • I don't want to have to deal with the possibility of changed object state
  • 我不想讨论对象状态改变的可能性

Which do you prefer and why?

你喜欢哪一种,为什么?

7 个解决方案

#1


3  

Yeah the first one is definitely better. I would never go for the second method. But you should think of using polymorphism more. Relying on instanceof so heavyly is not good OO design.

第一个肯定更好。我永远不会采用第二种方法。但是您应该考虑更多地使用多态性。依赖这样重量级的实例不是好的OO设计。

#2


8  

I prefer the first version for all the reasons you've mentioned. In particular (just to spell out your fourth point), it means you're definitely going to get consistent results... you could get horribly nasty results with the second version if getVehicle() returned a Car on the first call, then a Bike on the second...

由于你提到的所有原因,我更喜欢第一个版本。特别地,这意味着你肯定会得到一致的结果……如果getVehicle()在第一次调用时返回一辆汽车,然后在第二次调用时返回一辆自行车,那么在第二个版本中您可能会得到非常糟糕的结果……

The performance side doesn't bother me (I'll happily call List.size() repeatedly, for example) but readability, consistency and non-repeating are all much more important. Essentially the first snippet conveys the idea of "get a value, then use it" much more effectively than the second does.

性能方面我并不介意(例如,我很高兴地多次调用List.size())),但可读性、一致性和非重复性都要重要得多。从本质上讲,第一个片段传达了“获取一个值,然后使用它”的思想,比第二个片段更有效。

So yes, I'm with you... is anyone recommending the second form to you?

是的,我支持你……有人向你推荐第二种形式吗?

#3


2  

I normally dislike the introduction of extra variables as every bit of added state makes a method more complex. But even I'd say that it's warranted in your example since the variable replaces 4 repetitions of identical code.

我通常不喜欢引入额外变量,因为每个添加的状态都会使方法更加复杂。但是即使我在你的例子中说它是有根据的因为这个变量替换了4个重复的相同代码。

But the variable should definitely be final!

但是变量应该是最终的!

#4


1  

I agree, but I also try to reduce use of 'instanceof' too, at the class design level.

我同意,但我也试图减少在类设计级别上使用“instanceof”。

#5


1  

I personally think the first one is cleaner. However, provided the called method is not something computation intensive, it doesn't matter much.

我个人认为第一个更干净。但是,只要所调用的方法不是计算密集型的,它就不重要。

Probably the second is a bit faster (if you use Java 1.6) because in the first example you make a copy of the variable, while the java VM will be likely to inline the function call in both examples. Of course optimization is never an argument with calls like this. The compiler does so many optimizations that we shouldn't bother (often it'll just reduce the speed because we dont' know it well enough).

可能第二个要快一点(如果您使用Java 1.6),因为在第一个示例中,您复制了变量,而Java VM很可能在两个示例中内联函数调用。当然,优化从来都不是像这样调用的参数。编译器做了太多的优化,所以我们不需要费心(通常它只会降低速度,因为我们不太了解它)。

#6


1  

As everybody that answered this question so far, I definitely prefer the first style. It can be even cleaner though:

到目前为止,每个人都回答了这个问题,我肯定更喜欢第一种风格。它甚至可以更干净:

Vehicle vehicle = person.getVehicle()
if (vehicle instanceof Car) {
   ((Car) vehicle).openSunroof();
} else if (vehicle instanceof Bike) {
   ((Bike) vehicle).foldKickstand();
}

#7


1  

Both examples need some work. Try to push the behavior into an abstract (or protected) method on Vehicle. If this is code you can't modify, use composition to put it inside of an interface in your code base so that you don't have to pollute the rest of your code with the poor design of the library you're using. This is definitely a code smell. See "Replace Conditional with Polymorphism" in Fowler's Refactoring book.

这两个例子都需要一些工作。尝试将行为推入车辆上的抽象(或受保护)方法。如果这是您不能修改的代码,那么使用组合将其放在代码库中的接口中,这样您就不必使用您正在使用的库的糟糕设计来污染代码的其余部分。这绝对是一种代码味道。参见Fowler的重构书中的“用多态性替换条件”。


推荐阅读
author-avatar
王德筠宛吟玟华
这个家伙很懒,什么也没留下!
PHP1.CN | 中国最专业的PHP中文社区 | DevBox开发工具箱 | json解析格式化 |PHP资讯 | PHP教程 | 数据库技术 | 服务器技术 | 前端开发技术 | PHP框架 | 开发工具 | 在线工具
Copyright © 1998 - 2020 PHP1.CN. All Rights Reserved | 京公网安备 11010802041100号 | 京ICP备19059560号-4 | PHP1.CN 第一PHP社区 版权所有