將代碼分成塊是好習慣嗎？

Question

如果我有一個方法可以處理多個相關的事情，那麼將這個方法所做的每個「事情」粘貼到一個單獨的塊中是否是一個好習慣？

Ex。

{ 
int var 
//Code 
} 

{ 
int var 
//More Code 
} 

這將有助於減少局部變量的數量，使代碼更易讀，但我不知道這是否是一個好主意。

Answer 1

那麼，儘可能地限制變量的範圍當然是一個好習慣。它們不太可能被不必要地重複使用，並且在聲明它們時更容易定義它們，這樣可以避免由於未定義的變量等造成的錯誤。還有很多情況下，你有一個對象在構造它時被破壞，並且它想要調整它的範圍（例如，MFC中的小時玻璃會在其對象存在時顯示並在MFC中銷燬時消失;用於鎖定和解鎖互斥鎖的對象是另一個很好的例子），在這種情況下，使用大括號來確定變量的範圍是很有意義的。因此，有很多情況下，專門爲範圍變量創建代碼塊是非常有意義的。

但是，這麼做有很多問題。

1. 如果函數中有很多代碼塊，可能會變得很難閱讀。

2. 如果您嘗試儘可能嚴格地限定變量的範圍，那麼您遇到的問題是不得不聲明變量，這些變量需要比您更早地進行更大範圍確定，並且在聲明它們時並不總是能夠定義它們。

3. 函數經常表達你想要做的更好。

因此，使用額外的大括號範圍變量可以是很好的做法（減少變量範圍儘可能合理地肯定），但在許多情況下，它遠遠不如分手代碼爲多個功能。代碼的命名功能比任意代碼塊更容易理解。所以，如果你想要在一個函數中聲明很多獨立的代碼塊，可以考慮把它分解成多個函數 - 如果每個塊都直接在函數中，而不是進一步嵌套。所以，

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

    { 
     ... 
    } 
} 

的情況可能會更好地分成多個功能比單獨的塊。

當然有時候單獨的塊可以很好用，但通常單獨的函數會更好。

Answer 2

如果你的函數做了很多冗長的事情，你可以考慮把這些東西分成塊，那麼你應該把函數分成多個小函數。

當然，引入新的作用域塊的場景很有用。例如，如果您使用某種類型的scoped_lock來鎖定互斥鎖或其他同步對象，則可以通過引入一個作用域塊來確保僅鎖定所需的鎖定時間。

Answer 3

當面對這個時，我會做的第一件事就是考慮重構來將函數分解成更小的更具內聚性的函數。

最終，雖然歸結爲可讀性，但如果確定代碼的範圍使其更具可讀性，那麼這可能是一個好主意。另一方面，如果人們看到你的代碼會讓人迷惑，那麼你應該避免它。

Answer 4

如果你有一個方法可以處理多個相關的事情，我會說它打破了單一責任原則。 SRP是指對象，但我喜歡同樣地將相同的思想應用於方法和功能。將方法所做的每個「事物」粘貼到單獨的方法（可能是私有的或受保護的）並將其包裝在當前方法中將是一種很好的做法。請參閱Extract Method重構。

任何你可以做的事使你的代碼更具可讀性是一個好主意！做一件事的小功能比做許多事情的長功能更具可讀性。它們也更可重用。

Answer 5

Kent Beck的實施模式在這個話題上有非常好的篇章。拆分成塊將有助於重構成單獨的函數。

例如像這樣

void process() { 
//code for input 
//code for increments /tally 
//code to populate objects and output 
} 

將成爲

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