[arp242]

I've also used scopes for this:

  func DownloadAndVerifyThing(path string) error {
      var url string
      { // Build URL
         ...
         url = [..]
      }
  
      { // Fetch
          ...
      }
  
      { // Verify file.
          ...
      }
  }

I don't do this very often (and I'm having trouble locating an example off-hand, although I'm sure there must be a few in my public code), but it can be pretty useful at times.

[_a_a_a_]

I have and do use this for my 'normal' code, but not very often. I tend to prefer breaking things up into functions (usually named, not lambdas). Where I do use this style extensively is in self-testing code:

    // set up data to be tested
    var fred = ...
    var cathy = ...

    { // check fred does something correctly
        var result = fred.reproduce(2);
        assert(result.length() == 2, "fred should have 2 children");
    }

This prevents variable result from escaping and contaminating the next test, which happened an awful lot before I started doing this.

Then maybe better ways; suggestions welcome.

[ramses0]

Both _awesome_ comments, I made a similar one up above, but hadn't considered the `testing` use case which is actually really really cool to "protect" your test scope like that. Almost like a fake "setup/teardown".

[whstl]

A different pattern I like in Ruby is the assignment with begin...end:

    fred = begin
      user_finder = ...
      user_finder.find('fred')
    end

Again, not always "self-documenting" as whipping out a new function, but useful if you need to separate chunks and keep the code linear.

The only issue with Ruby itself is that the scope is not lexical, so you can still use `user_finder` outside the block above (linters can catch it, though). But it's still worth to separate code without having a brand new method.