if-continue vs嵌套if

时间:2015-11-26 17:24:51

标签: java continue nested-if

我正在实施一些碰撞检测。随着时间的推移,随着项目复杂性的不断增加,不断添加额外的检查,我偶然发现了一个如下所示的模式:

for (GameObject o1 : collisionObjects) {
    for (GameObject o2 : collisionObjects) {
        if(o1 == o2){
            continue;
        }

        if(!(o1.isSolid() && o2.isSolid())){
            continue;
        }

        //several more checks

        //all of the early-out conditions are passed so do
        //do some intersection checks here

    }
}

稍后查看整个累积的代码,我想如果我要重构这个,我会使用嵌套的ifs:

for (GameObject o1 : collisionObjects) {
    for (GameObject o2 : collisionObjects) {
        if(o1 != o2){
            if(o1.isSolid() && o2.isSolid()){
                 //all conditions are met so do collision detection
            }
        }
    }
}

从可读性的角度来看,我非常喜欢第一个例子,因为它清楚地突破了所有条件,并且不会给我留下深层次的嵌套ifs。 从效率的角度来看,第一个要求每次都进行更多的比较。

哪种方法更好?我是否通过使用第一个而不是第二个而无意中调用了任何副作用?

2 个答案:

答案 0 :(得分:1)

如果您担心第一次需要更多检查,为什么不否定您的逻辑并将第二个if语句折叠到第一个? e.g。

if(o1 != o2 && o1.isSolid() && o2.isSolid()) {
    // extra stuff
}

对布尔逻辑进行惰性分析,一旦达到false,语句就会失败。

如果您关注性能,我认为FAR更重要的是要研究碰撞检测策略。例如,Oct-trees,BSP等。

答案 1 :(得分:0)

  

我是否因使用第一种而非第二种而无意中调用了任何副作用?

两者都很好,我没有看到一个优于另一个的任何显着优势。

但是如果你是认真的并且想要创造一些有效的东西(例如在拥有成千上万个物体的3D世界中一致地检查碰撞),你将会看到树。特别是 quad-tree 。这就是游戏实际进行碰撞检测的方式。

如果你在学校学习游戏,这是一个相当大的话题。