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

如果你的方法太大而你觉得你需要像那样组织它们，你应该把它们分成更小的方法。（我从经验中说：我有一种可怕的习惯，就是编写过长的方法，这些方法很难维护。我必须每天都要对抗它。）

至于它是否是糟糕的做法，我会说它本身并不存在，除了它是如此不寻常以至于它会让人们对你的代码进行维护。他们会在块的开头寻找东西 - if或while等等 - 当它不存在时会感到惊讶。所以从这个意义上说，这可能不是很好的做法，因为捣乱维护代码的人通常不是一个好主意。

Answer 3

我不认为这是不好的做法，我也这样做，但我鼓励你把方法分解成更小的方法。你真的需要一个＆gt; 50行的方法吗？

Answer 4

这取决于块的作用。如果它们被用来限制局部变量的范围，那么我认为这是一个好主意。人们倾向于给变量提供范围太大的范围，并且在调试或查看代码时，变量范围的明确结束有很大帮助。

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

Answer 5

没关系。您应该随意这样做，因为隔离变量是一种很好的做法。您可以将这些作用域块作为一种就地匿名函数来阅读，这有时可以作为一种将代码视觉组合在一起的方法，当然，每次执行此操作时，您应该问自己“我应该将它实际分开吗？功能？“，正如其他帖子所建议的那样。

它可以实现的另一个有用的东西，特别是如果你使用自动格式化块的代码感知编辑器，是缩进重要的和专业的代码段，否则不会缩进。 e.g：

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()更短，这与保持函数简短的良好编码实践一致。

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

将一个方法中的代码段与大括号分开是不好的做法？

6 个答案: