例如:
{
int var
//Code
}
{
int var
//More Code
}
这样做能够减少本地变量的数量并使代码更易读,但我不确定是否是一个好主意。
{
int var
//Code
}
{
int var
//More Code
}
这样做能够减少本地变量的数量并使代码更易读,但我不确定是否是一个好主意。
如果您的函数执行多个事情,而这些事情足够复杂,您会考虑将这些事情拆分成块,则应该将该函数拆分为多个更小的函数。
当然,某些情况下引入新的作用域块会很有用。例如,如果您使用某种scoped_lock
来锁定互斥或其他同步对象,则可以通过引入作用域块来确保您只在必要的时间内持有锁。
void process() {
//code for input
//code for increments /tally
//code to populate objects and output
}
将变成
void process() {
input();
tally();
output();
}
面对这种情况,我首先会考虑重构代码,将函数分解成更小、更有凝聚力的函数。
但最终还是要看代码的可读性。如果限定作用域可以使代码更易读,那么这可能是个好主意。但如果反而会让其他人看你的代码时感到困惑,那么最好还是避免使用。
在编程中,尽可能限制变量的作用域是一种好的实践。这样可以减少不必要的重复使用,并且在声明变量时更容易定义它们,避免由于未定义变量等问题导致的错误。此外,有很多情况下,你需要一个对象在构造时执行某些操作,在销毁时执行其他操作(例如,在MFC中,沙漏对象在存在时显示,在销毁时消失;锁定和解锁互斥量的对象也是一个很好的例子),在这种情况下,使用大括号来限定变量的作用域是很有意义的。因此,有很多情况下,创建代码块以限定变量的作用域是很有意义的。
然而,过度使用这种方法也会带来一些问题:
如果在函数中有很多代码块,阅读起来会变得困难。
如果过于强调变量的作用域,就会遇到需要在较早的阶段声明需要更大作用域的变量,而不能总是在声明时定义它们的问题。
函数通常能更好地表达你想要做的事情。
所以,使用额外的大括号来定义变量的作用域可能是一个好的做法(尽可能地减小变量的作用域当然是好的),但在许多情况下,将代码分解为多个函数会更好。当你有具名函数而不是任意的代码块时,代码会更容易理解。因此,如果你在一个函数中要声明很多个独立的代码块,考虑将其拆分为多个函数——特别是如果这些代码块都直接位于函数内部而不是嵌套更深层次的情况。所以,在
T func(...)
{
{
...
}
{
...
}
}
将其分解为多个函数可能比分开的块更好。
当然,有时候分开的块是好的和有用的,但通常分开的函数会更好。