用大括号在一种方法中分隔代码段是不好的做法吗？ [关闭]

Question

我倾向于将完成某个任务的多行代码放入块中，并在顶部加上一个小注释，如下所示：

public void doSomething(){
    // common variables needed by all blocks

    { // comment for block 1
        ...
        ... about 5 to 30 lines of code
        ...
    }

    { // comment for block 2
        ...
        ... about 5 to 30 lines of code
        ...
    }

}

我这样做是因为在我看来，它很容易阅读，一个块所需的变量不会对另一个块造成伤害，而且因为我不想为块创建单独的方法在其他地方需要。

你会说这是不好的做法吗？ 很多与我一起编码的人不同意这种编码风格。 我知道 c# 中有区域，但它们不会隔离变量。

编辑： 因为每个人都建议我从块中制作方法： 有时我会这样做，但如果该类已经有 20 多个方法，任何其他方法都不需要这些块并且包含所有块的方法仍然足够小，我不想这样做。

Answer 1

如果你可以像这样分解代码，为什么不把它分解成单独的方法呢？然后将您的doSomething() 方法更改为只是调用那些较小的方法？

这样：

• 作品的每个元素的用途很清楚
• 阅读顶层方法，很容易看到整体计划并深入到一个特定的部分
• 您可以单独对每个小方法进行单元测试（尽管这可能需要将其设为非私有仅用于测试；这是否可以与其他任何事情一样取决于个人喜好）

Answer 2

我不认为这是一种不好的做法，我也这样做，但我鼓励您将方法分解为更小的方法。你真的需要 >50 行的方法吗？

Answer 3

如果您的方法太大以至于您觉得需要这样组织它们，那么您很有可能应该将它们分解成更小的方法。 （我从经验中说：我有一个可怕的习惯，即编写过长的方法，这很难维持。我必须每天都在与它作斗争。）

至于它是否是不好的做法，我想说它本身并不是，只是它非常不寻常，以至于它往往会让人们对你的代码进行维护。他们会在区块的开头寻找那个东西——if，或while，等等——当它不存在时会感到惊讶。所以从这个意义上说，这可能不是一个好习惯，因为让维护代码的人绊倒通常不是一个好主意。

Answer 4

这取决于块的作用。如果它们用于将局部变量的范围限制为合理的范围，我认为这是一个好主意。人们倾向于给变量的范围过于宽泛，而明确的变量范围结束在调试或审查代码时会大有帮助。

话虽如此，如果一个部分中的代码较长，并且它与其他部分共享的变量数量很少，那么重构也许是个好主意。

Answer 5

没关系。您应该随意这样做，因为隔离变量是一种很好的做法。您可以将这些作用域块作为一种就地匿名函数来阅读，这有时可用作将代码直观地组合在一起的一种方式，尽管您当然每次这样做时都应该问自己“我真的应该把它单独功能？”，正如此处其他帖子所建议的那样。

它可以实现的另一个有用的事情，特别是如果您使用的是自动格式化块的代码感知编辑器，那就是缩进重要且专业的代码部分，否则这些部分不会被缩进。例如：

glBegin(GL_TRIANGLES); {
    glVertex3f( 0.0f, 1.0f, 0.0f);
    glVertex3f(-1.0f,-1.0f, 0.0f);
    glVertex3f( 1.0f,-1.0f, 0.0f);
}; glEnd();

Answer 6

你的编码风格很不寻常，我不确定每个人都会觉得它很容易阅读。 大括号本身会降低代码的可读性，因此您应该尽可能省略它们。例如。而不是

if(n == 1)
{
   i++;
}

只写：

if(n == 1)
   i++;

仅仅为了在同一个函数中分隔不同的功能块而引入的作用域听起来也不对——将它们提取到单独的函数中会更自然。最大的好处之一是您可以更轻松地测试它们并单独测试它们。这将使doSomething() 更短，这再次符合保持函数short 的良好编码实践。

您为函数内的作用域编写的 cmets 不能出现在自动生成的文档中。如果您使用单独的函数并将这些 cmets 应用于它们（假设它们遵循给定的自动文档生成工具的语法，例如 Doxygen），它们将出现在文档中。