12

In C++, is it bad practice create blocks of code inside some function, such as the following:

    bool f()
    {
       {
           double test = 0;

           test = // some other variable outside this function, for example.

           if (test == // some value)
             return true;
       }

       {
           double test = 0;

           test = // some variable outside this function, different from the last one.

           if (test == // some value)
             return true;
       }

       return false;

    }

The point of doing this would be to use the same variable name of "test" multiple times, for the same type of procedure. In actual my project, I have multiple variables and am performing multiple tests. I don't really want to keep creating new variables with different names for each of the tests, considering how the tests are so similar.

Is it bad practice to insert blocks of code so that the variables go out of scope after each test, and then I can use their names again? Or should I seek another solution? It should be noted that I considered using the same set of variables for all my tests (and just setting them all to 0 after each test was over), but I was under the impression this may be bad practice.

  • 19
    If I were reveiwing this code, I would tell you to separate each of these tests into individual methods... As a consequence you wouldn't need to use code blocks to scope them seperately. – Maybe_Factor Nov 2 '17 at 4:34
  • 1
    @Maybe_Factor - I agree. Benefit of separate methods is that you can name each block, providing a more readable code. – mouviciel Nov 2 '17 at 8:54
  • @mouviciel Not just more readable code, but more readable test reports! – Maybe_Factor Nov 2 '17 at 23:01
  • @Maybe_Factor I disagree. Moving things into separate functions has the negative effect of making them seem like little reusable bits of functionality. Keeping all the logic for a function in one place is good. – Miles Rout Nov 7 '17 at 22:19
  • 1
    @MilesRout This isn't one logical function, this is multiple unit tests for a function all crammed into a single test function. Code blocks vs functions in normal code is another discussion entirely. – Maybe_Factor Nov 8 '17 at 5:15
22

Blocks are perfectly reasonable if you're using them to scope some resource. Files, network connections, memory allocations, database transactions, whatever. In those cases, the block is actually part of the logical structure of the code: you spawn a resource, it exists for some period of time, and then it goes away at a designated time.

But if all you're doing is scoping a name, then I would say that they are bad practice. Generally speaking, of course; special circumstances can apply.

For example, if this function were generated by some code generation system, testing framework, or the like, then blocks for the sake of name scoping is a reasonable thing. But you'd be talking about code written for the purpose of a machine, not a human.

If a human is writing code where they need to reuse names within the same function, I would say that those blocks probably need to be separate functions. Especially if those names are being used with different types and/or meaning within those blocks.

10

It is not bad practice to create blocks like this. It's how scopes work.

Usually this is done when using RAII (Resource Acquisition is Initialization) and you want to control when the destructors get called.

If it gets long, I would consider moving that code to it's own function.

In my opinion just using it to recycle variable names is not a good idea. But I can see it been useful in cases with low memory

  • Reuse of local variable names has no effect on memory use. – kevin cline Nov 2 '17 at 6:04
  • 1
    Don't you think that a smart optimizer could use 1 memory location for the 2 variables? – Robert Andrzejuk Nov 2 '17 at 8:11
  • 3
    Yes. But it can also do that if they're in the same scope, if they don't have destructors. – Sebastian Redl Nov 2 '17 at 9:14

Your Answer

By clicking "Post Your Answer", you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.