将代码分成块是一种好的实践吗?

7
如果我有一个方法可以做多个相关的事情,将该方法所做的每个“事情”分别放入不同的块中,这样做是好的实践吗?
例如:
{
int var
//Code
}

{
int var
//More Code
}

这样做能够减少本地变量的数量并使代码更易读,但我不确定是否是一个好主意。

5个回答

15

如果您的函数执行多个事情,而这些事情足够复杂,您会考虑将这些事情拆分成块,则应该将该函数拆分为多个更小的函数。

当然,某些情况下引入新的作用域块会很有用。例如,如果您使用某种scoped_lock来锁定互斥或其他同步对象,则可以通过引入作用域块来确保您只在必要的时间内持有锁。


4
肯特·贝克的《实现模式》一书中有一章非常好地讲解了这个主题。将代码划分成块有助于重构为单独的函数。
例如,像这样的代码:
void process() { 
 //code for input 
 //code for increments /tally 
 //code to populate objects and output 
}

将变成

void process() {
  input();
  tally();
  output();
}

3

面对这种情况,我首先会考虑重构代码,将函数分解成更小、更有凝聚力的函数。

但最终还是要看代码的可读性。如果限定作用域可以使代码更易读,那么这可能是个好主意。但如果反而会让其他人看你的代码时感到困惑,那么最好还是避免使用。


3
如果您有一个同时执行多个相关任务的方法,我会认为它正在违反单一责任原则。SRP是针对对象的,但我同样喜欢将相同的思想应用于方法和函数。最好将方法执行的每个“任务”分别封装到单独的方法中(可能是私有或受保护的),并在当前方法中包装这些方法。参见Extract Method重构。
任何使代码更易读的操作都是明智的!做一件事情的较小函数比执行多项任务的长函数更易读。它们也更易于重复使用。

0

在编程中,尽可能限制变量的作用域是一种好的实践。这样可以减少不必要的重复使用,并且在声明变量时更容易定义它们,避免由于未定义变量等问题导致的错误。此外,有很多情况下,你需要一个对象在构造时执行某些操作,在销毁时执行其他操作(例如,在MFC中,沙漏对象在存在时显示,在销毁时消失;锁定和解锁互斥量的对象也是一个很好的例子),在这种情况下,使用大括号来限定变量的作用域是很有意义的。因此,有很多情况下,创建代码块以限定变量的作用域是很有意义的。

然而,过度使用这种方法也会带来一些问题:

  1. 如果在函数中有很多代码块,阅读起来会变得困难。

  2. 如果过于强调变量的作用域,就会遇到需要在较早的阶段声明需要更大作用域的变量,而不能总是在声明时定义它们的问题。

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

所以,使用额外的大括号来定义变量的作用域可能是一个好的做法(尽可能地减小变量的作用域当然是好的),但在许多情况下,将代码分解为多个函数会更好。当你有具名函数而不是任意的代码块时,代码会更容易理解。因此,如果你在一个函数中要声明很多个独立的代码块,考虑将其拆分为多个函数——特别是如果这些代码块都直接位于函数内部而不是嵌套更深层次的情况。所以,在

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

    {
        ...
    }
}

将其分解为多个函数可能比分开的块更好。

当然,有时候分开的块是好的和有用的,但通常分开的函数会更好。


网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接