[ACCEPTED]-Do you use curly braces for additional scoping?-java

I do if I am using a resource which I want 1 to free at a specific time eg:

void myfunction()
{
  {
  // Open serial port
     SerialPort port("COM1", 9600);
     port.doTransfer(data);
  } // Serial port gets closed here.

  for(int i = 0; i < data.size(); i++)
     doProcessData(data[i]);
  etc...
}

I would not use curly braces for that purpose 9 for a couple reasons.

1. If your particular 8 function is big enough that you need to 7 do various scoping tricks, perhaps break 6 the function into smaller sub-functions.

2. Introducing 5 braces for scoping to reuse variable names 4 is only going to lead to confusion and trouble 3 in code.

Just my 2 cents, but I have seen 2 a lot of these types of things in other 1 best practice materials.

C++:

Sometimes you need to introduce an extra 3 brace level of scope to reuse variable names 2 when it makes sense to do so:

switch (x) {
    case 0:
        int i = 0;
        foo(i);
        break;
    case 1:
        int i = 1;
        bar(i);
        break;
}

The code above 1 doesn't compile. You need to make it:

switch (x) {
    case 0:
        {
            int i = 0;
            foo(i);
        }
        break;
    case 1:
        {
            int i = 1;
            bar(i);
        }
        break;
}

The most common "non-standard" use of scoping 5 that I use regularly is to utilize a scoped 4 mutex.

void MyClass::Somefun()
{
    //do some stuff
    {
        // example imlementation that has a mutex passed into a lock object:
        scopedMutex lockObject(m_mutex); 

        // protected code here

    } // mutex is unlocked here
    // more code here
}

This has many benefits, but the most 3 important is that the lock will always be 2 cleaned up, even if an exception is thrown 1 in the protected code.

The most common use, as others have said, is 5 to ensure that destructors run when you 4 want them to. It's also handy for making 3 platform-specific code a little clearer:

#if defined( UNIX )
    if( some unix-specific condition )
#endif
    {
        // This code should always run on Windows but 
        // only if the above condition holds on unix
    }

Code 2 built for Windows doesn't see the if, only 1 the braces. This is much clearer than:

#if defined( UNIX )
    if( some unix-specific condition ) {
#endif
        // This code should always run on Windows but 
        // only if the above condition holds on unix
#if defined( UNIX )
    }
#endif

It can be a boon to code generators. Suppose 8 you have an Embedded SQL (ESQL) compiler; it 7 might want to convert an SQL statement into 6 a block of code that needs local variables. By 5 using a block, it can reuse fixed variable 4 names over and over, rather than having 3 to create all the variables with separate 2 names. Granted, that's not too hard, but 1 it is harder than necessary.

As others have said, this is fairly common 9 in C++ due to the all-powerful RAII (resource 8 acquisition is initialization) idiom/pattern.

For 7 Java programmers (and maybe C#, I don't 6 know) this will be a foreign concept because 5 heap-based objects and GC kills RAII. IMHO, being 4 able to put objects on the stack is the 3 greatest single advantage of C++ over Java 2 and makes well-written C++ code MUCH cleaner 1 than well-written Java code.

I only use it when I need to release something 3 by the means of RAII and even then only 2 when it should be released as early as I 1 possibly can (releasing a lock for example).

Programming in Java I have quite often wanted 23 to limit scope within a method, but it never 22 occurred to me to use a label. Since I 21 uppercase my labels when using them as the 20 target of a break, using a mixed case labeled 19 block like you have suggested is just what 18 I have wanted on these occasions.

Often the 17 code blocks are too short to break out into 16 a small method, and often the code in a 15 framework method (like startup(), or shutdown()) and 14 it's actually better to keep the code together 13 in one method.

Personally I hate the plain 12 floating/dangling braces (though that's 11 because we are a strict banner style indent 10 shop), and I hate the comment marker:

// yuk!
some code
{
scoped code
}
more code

// also yuk!
some code
/* do xyz */ {
    scoped code
    }
some more code

// this I like
some code
DoXyz: {
    scoped code
    }
some more code

We 9 considered using "if(true) {" because the 8 Java spec specifically says these will be 7 optimized away in compilation (as will the 6 entire content of an if(false) - it's a 5 debugging feature), but I hated that in 4 the few places I tried it.

So I think your 3 idea is a good one, not at all silly. I 2 always thought I was the only one who wanted 1 to do this.

Yes, I use this technique because of RAII. I 8 also use this technique in plain C since 7 it brings the variables closer together. Of 6 course, I should be thinking about breaking 5 up the functions even more.

One thing I do 4 that is probably stylistically controversial 3 is put the opening curly brace on the line 2 of the declaration or put a comment right 1 on it. I want to decrease the amount of wasted vertical space. This is based on the Google C++ Style Guide recommendation..

/// c++ code
/// references to boost::test
BOOST_TEST_CASE( curly_brace )
{
  // init
  MyClass instance_to_test( "initial", TestCase::STUFF ); {
    instance_to_test.permutate(42u);
    instance_to_test.rotate_left_face();
    instance_to_test.top_gun();
  }
  { // test check
    const uint8_t kEXP_FAP_BOOST = 240u;
    BOOST_CHECK_EQUAL( instance_to_test.get_fap_boost(), kEXP_FAP_BOOST);
  }
}

I agree with agartzke. If you feel that 4 you need to segment larger logical code 3 blocks for readability, you should consider 2 refactoring to clean up busy and cluttered 1 members.

It has its place, but I don't think that 7 doing it so that $foo can be one variable 6 here and a different variable there, within the same 5 function or other (logical, rather than 4 lexical) scope is a good idea. Even though 3 the compiler may understand that perfectly, it 2 seems too likely to make life difficult 1 for humans trying to read the code.

The company I'm working at has a static 11 analysis policy to keep local variable declarations 10 near the beginning of a function. Many times, the 9 usage is many lines after the first line 8 of a function so I cannot see the declaration 7 and the first reference at the same time 6 on the screen. What I do to 'circumvent' the 5 policy is to keep the declaration near the 4 reference, but provide additional scope 3 by using curly braces. It increases indentation 2 though, and some may argue that it makes 1 the code uglier.