title: Named blocks to limit variable scope: good idea?
body: <p>For years, I've been using named blocks to limit the scope of temporary variables.  I've never seen this done anywhere else, which makes me wonder if this is a bad idea.  Especially since the Eclipse IDE flags these as warnings by default.</p>
  
  <p>I've used this to good effect, I think, in my own code.  But since it is un-idiomatic to the point where good programmers will distrust it when they see it, I really have two ways to go from here:  </p>
  
  <ol>
  <li>avoid doing it, or </li>
  <li>promote it, with the hope that it will become an idiom.</li>
  </ol>
  
  <p>Example (within a larger method):</p>
  
  <pre><code>final Date nextTuesday;
  initNextTuesday: {
      GregorianCalendar cal = new GregorianCalendar();
      ... // About 5-10 lines of setting the calendar fields
      nextTuesday = cal.getTime();
  }
  </code></pre>
  
  <p>Here I'm using a GregorianCalendar just to initialize a date, and I want to make sure that I don't accidentally reuse it.</p>
  
  <p>Some people have commented that you don't actually need to name the block.  While that's true, a raw block looks even more like a bug, as the intent is unclear.  Furthermore, naming something encourages you to think about the intention of the block.  The goal here is to identify distinct sections of code, not to give every temporary variable its own scope.</p>
  
  <p>Many people have commented that it's best to go straight to small methods.  I agree that this should be your first instinct.  However, there may be several mitigating factors:</p>
  
  <ul>
  <li>To even consider a named block, the code should be short, one-off code that will never be called elsewhere.</li>
  <li>A named block is a quick way to organize an oversized method without creating a one-off method with a dozen parameters.  This is especially true when a class is in flux, and the inputs are likely to change from version to version.</li>
  <li>Creating a new method encourages its reuse, which may be ill-advised if the use cases aren't well-established.  A named block is easier (psychologically, at least) to throw away.</li>
  <li>Especially for unit tests, you may need to define a dozen different objects for one-off assertions, and they are just different enough that you can't (yet) find a way to consolidate them into a small number of methods, nor can you think of a way to distinguish them with names that aren't a mile long.</li>
  </ul>
  
  <p>Advantages of using the named scope:</p>
  
  <ol>
  <li>Can't accidentally reuse temporary variables</li>
  <li>Limited scope gives garbage collector and JIT compiler more information about programmer intent</li>
  <li>Block name provides a comment on a block of code, which I find more readable than open-ended comments</li>
  <li>Makes it easier to refactor code out of a big method into little methods, or vice versa, since the named block is easier to separate than unstructured code.</li>
  </ol>
  
  <p>Disadvantages:</p>
  
  <p>Not idiomatic: programmers who haven't seen this use of named blocks (i.e. everyone but me) assume it's buggy, since they can't find references to the block name.  (Just like Eclipse does.)  And getting something to become idiomatic is an uphill battle.</p>
  
  <p>It can be used as an excuse for bad programming habits, such as:</p>
  
  <ul>
  <li>Making huge, monolithic methods where several small methods would be more legible.</li>
  <li>Layers of indentation too deep to read easily.</li>
  </ul>
  
  <p>Note:  I've edited this question extensively, based on some thoughtful responses.  Thanks!</p>