在 for 循环内部或外部添加条件以获得更清晰的代码更好吗？

Question

所以这听起来可能很简单，但我有一个内部有 for 循环的方法，在 forloop 内部，方法 createprints 需要从 getParameters 获取的“参数”映射，现在有两种类型的报告，一种有一个通用的参数集，而另一个具有该通用集和自己的一组参数。

我有两个选择：

有两个getparameters方法，一个是通用的，另一个是用于rp2但也调用通用参数方法。如果我这样做，那么在 for 循环之前添加条件是有意义的：

    theMethod(){

        if (rp1){
            for loop{
                createPrints(getgenParameters())
                do general forloop stuff 
           }
        }else{
              for loop{
                createPrints(getParameters())
                do general forloop stuff
                }
        }
    }

这样，它只检查一次要调用的参数方法，而不是在循环中使用 if 语句，以便检查每次迭代（这很糟糕，因为报告类型在整个循环中永远不会改变）但是这样，重复for 循环看起来很丑，而且根本不干净，有没有更干净的方法来设计它？

另一种选择是将布尔值传递给 get parameters 方法，基本上您可以检查它是哪种类型的报告，并根据您创建的地图，但是这也会在每次迭代时添加一个条件。

从性能的角度来看，将条件放在循环之外是有意义的，这样它就不会在每次迭代时进行冗余检查，但它看起来并不干净，而且我的老板真的很关心代码看起来有多干净，他不喜欢我使用一个 if else 代码块，而不是使用三元运算符，因为三元只使用一行（我认为性能仍然相同吗？）。

忘了说我用的是java，我不能给变量分配函数或使用回调 在方法内部，在 for 循环之前有一个 if else 代码块，类似于

String aVariable;

if(condition){
aVariable= value1;
}else{
aVariable =value2;
}

所以我最初只想创建一个像 isreport1 这样的布尔变量，并且在 if/else 代码块内部也分配值，因为它使用相同的条件。然后如前所述传入参数但是，我的老板又说不要在参数中使用布尔值，所以这种情况我不应该在这里做吗？

Answer 1

分支预测是 CPU 的属性，而不是编译器的属性。所有现代 CPU 都有它，不用担心。

大多数编译器都可以从循环中拉出一个常量条件，所以不要再担心了。 Java 也这样做。详细信息：javac 编译器不这样做，它的工作是将源代码转换为字节码，仅此而已。但在运行时，字节码的时间关键部分会在机器中编译，并且会发生许多优化。

忘了说我用的是java，我不能给变量分配函数或使用回调。

你可以。它是通过匿名类实现的，从 Java 8 开始，就有了 lambdas。当然值得学习，但与您的情况无关。

我会选择的

       for loop{
            createPrints(rp1 ? getgenParameters() : getParameters())
            do general forloop stuff 
       }

因为这是最短且最干净的方式。

有很多替代方法，例如定义Parameters getSomeParameters(boolean rp1)，您可以使用上述三元组中的“提取方法”轻松创建。

从性能的角度来看，将条件放在循环之外是有意义的，这样它就不会在每次迭代时进行冗余检查，但它看起来并不干净，我的老板真的很关心代码看起来有多干净

从性能的角度来看，这一切都无关紧要。编译器非常聪明，知道大量的优化。只需用简短的方法编写干净的代码，这样它就可以正常工作。

他不喜欢我使用 if else 代码块而不是使用三元运算符，因为三元只使用一行

一个简单的三元单行代码使代码更容易理解，所以你应该去做（复杂的三元可能很难掌握，但这里不是这样）。

（我认为性能还是一样不是吗？）。

当然。请注意

• 大多数程序部分与性能无关（帕累托原理）
• 低级优化很少重要（编译器更了解它们）
• 使用正确数据结构的干净代码很重要

Answer 2

大多数关于编写某段代码的方法是否比另一种更有效的“辩论”都没有抓住重点。

JIT 编译器在后台对您的代码执行大量优化。它（或者更准确地说是编写它的人）比你更了解如何优化。他们将拥有进行广泛的基准测试和（机器级）代码演练等的优势，以找出最佳的优化方法。

编译器还可以比人类更可靠地进行优化。它的开发者也在不断改进它。

并且编译器不需要支付薪水来优化代码。是的。您花在优化上的每一个小时都是您可以花在其他事情上的时间。

所以优化时最适合您的策略如下：

1. 首先实现代码。编码时花在优化上的时间可能被浪费了。这是经典的“过早优化”行为。在这个阶段，你的直觉可能不足以做出正确的决定。 （很少有人真正足够聪明......）
2. 接下来让代码工作并通过测试。优化有缺陷的代码没有抓住重点。
3. 设定一些现实的、可量化的绩效目标。 （“尽可能快”既不现实也不可量化）。您的代码只需要足够快即可满足业务需求。如果它已经足够快，那么您进一步优化它就是在浪费开发人员的时间。
4. 创建一个现实的基准，以便您可以衡量您的应用程序的性能。如果您不能（或不）进行衡量，您将不知道自己是否达到了目标，或者某个特定的优化尝试是否改善了情况。
5. 使用分析来确定代码的哪些部分值得努力优化。分析会告诉您花费大部分时间的热点。专注于那里……而不是只偶尔执行的东西。这就是 80-20 规则的用武之地。

我会和我的老板谈谈这件事。如果老板不同意在性能/优化方面有条不紊和科学的想法，那就不要抗拒。就按老板说的做。 （但是，如果您因在不必要的优化上浪费时间而错过最后期限而受到指责，那么当您愿意推迟时。）

软件工程有两种效率：

• 程序的效率
• 程序员的效率

这两种效率是冲突的。

Answer 3

这个怎么样？

theMethod(getParametersCallback){

        for loop {
            createPrints(getgenParametersCallback)
            do general forloop stuff 
       }
}

. . .  . .

if (rp1){
    theMethod(getgenParameters)
}
else {
    theMethod(getParameters)
}