将代码分成块是一种好习惯吗？

Question

如果我有一个方法可以执行多个相关的事情,那么将该方法所做的每个"事物"粘贴到一个单独的块中是一种好习惯吗？

防爆.

{
int var
//Code
}

{
int var
//More Code
}

它有助于减少局部变量的数量,并使代码更具可读性,但我不确定它是否是一个好主意.

Answer 1

如果你的函数做了很多冗长的事情,你会考虑将这些东西分成像这样的块,那么你应该将函数分成多个较小的函数.

当然,引入新范围块的情况很有用.例如,如果使用scoped_lock某种类型来锁定互斥锁或其他同步对象,则可以通过引入范围块来确保仅在必要时保持锁定一小段时间.

Answer 2

嗯，尽可能限制变量的范围当然是一个好习惯。它们不太可能被不必要地重用，并且您更有可能在声明它们时定义它们，这可以避免由于未定义的变量等导致的错误。还有很多情况下，您有一个对象在构造时和销毁时执行某些操作，并且您希望确定其范围（例如，MFC 中的沙漏在其对象存在时显示，在 MFC 中销毁时消失） ；用于锁定和解锁互斥体的对象是另一个很好的例子），在这种情况下，用大括号确定变量的作用域很有意义。因此，在很多情况下，专门为作用域变量创建代码块是很有意义的。

然而，大量这样做会带来一些问题。

1. 如果函数内有很多代码块，则可能会变得难以阅读。

2. 如果您过于努力地尽可能严格地限制变量的范围，则会遇到问题，必须提前声明需要更大范围的变量，并且在声明它们时并不总是能够定义它们。

3. 函数通常能表达你想要做得更好的事情。

因此，使用额外的大括号来确定变量的范围可能是一个很好的做法（当然是尽可能合理地减少变量的范围），但在许多情况下，最好将代码分解为多个函数。当您使用命名函数时，代码比任意代码块更容易理解。因此，如果您希望在函数中声明许多单独的代码块，请考虑将其分解为多个函数 - 如果每个代码块都直接位于函数内而不是在函数内，则尤其如此。进一步嵌套。所以，案例

T func(...)
{
    {
        ...
    }

    {
        ...
    }
}

分成多个功能可能比单独的块更好。

当然，有时单独的块可能是好的和有用的，但通常单独的功能会更好。