Is it good practice to separate code into blocks?

Question

If I have a method that does multiple, related things, is it good practice to stick each "thing" that the method does into a seperate block?

Ex.

{
int var
//Code
}

{
int var
//More Code
}

It would help reduce the number of local variables, and make the code more readable, but I'm not sure if it's a good idea.

Answer 1

If your function does multiple things that are lengthy enough that you would consider splitting those things into blocks like this, then you should probably split the function into multiple, smaller functions.

There are, of course, scenarios in which introducing a new scope block is useful. For example, if you use a scoped_lock of some kind to lock a mutex or other synchronization object, you can ensure that you only hold the lock for as short a time as necessary by introducing a scope block.

Answer 2

Implementation Patterns by Kent Beck has a very good chapter on this topic. Splitting into blocks will help in refactoring into separate functions.

For example something like this

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

will become

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

Answer 3

The first thing I'd do when faced with this is to consider refactoring to break the function up into smaller more cohesive functions.

Ultimately though it comes down to readability, if scoping the code makes it more readable then it's probably a good idea. If on the other hand it's going to confuse people looking at your code then you should probably avoid it.

Answer 4

If you have a method that does multiple, related things, I would say that it is breaking the Single Responsibility Principle. SRP refers to objects, but I like to apply the same thinking to methods and functions equally. It would be good practice to stick each "thing" that the method does into separate methods (probably private or protected) and wrap those in your current method. See the Extract Method refactoring.

Anything you can do to make your code more readable is a good idea! Smaller functions that do one thing are more readable than long functions that do many things. They're also more re-usable.

Answer 5

Well, it's certainly good practice to restrict the scope of variables as much as possible. They're less likely to be re-used unnecessarily, and you're more likely to define them when you declare them, which avoids bugs due to undefined variables and such. There are also plenty of cases where you have an object which does something while it's constructed and when it's destroyed, and you want to scope that (for instance, the hour glass in MFC is displayed while its object exists and disappears when it's destroyed in MFC; objects for locking and unlocking mutexes are another good example), and in such cases, scoping the variables with braces makes good sense. So, there are plenty of cases where it makes good sense to create blocks of code specifically to scope variables.

However, there are some problems with doing this heavily.

1. It can become hard to read if you have a lot of code blocks within a function.

2. If you try too hard to scope variables as tightly as possible, you run into issues with having to declare variables which need larger scoping earlier than you would otherwise and aren't always able to define them when declaring them.

3. Functions often express what you're trying to do far better.

So, using extra braces to scope variables can be good practice (reducing the scope of variables as much as reasonably possible certainly is), but in many cases, it's far better to break up your code into multiple functions. Code can be far easier to understand when you have named functions than arbitrary blocks of code. So, if you're in a position where you're looking to declare very many separate blocks of code within a function, consider breaking it up into multiple functions - this is especially true if each of those blocks is directly within the function rather than nested further. So, cases of

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

    {
        ...
    }
}

would likely be better broken into multiple functions than separate blocks.

There are certainly times when separate blocks can be good and useful, but generally separate functions would be better.