but do requires the extra semicolon! (And a lone do looks alien to C coders.)

I prefer the first: It shows that you're making a scope for $x and groups the code. I don't care for the others because there's a little extra mental overhead:

• With the BLOCK: version, I start looking for next or goto elsewhere. When I don't see it, I wonder why the label is there.
• The do { ... }; version is the least objectionable, but I do have to look at the end of the loop to see if there's a looping condition, etc.
• The if (1) version is particularly ugly to me. It looks like something is (potentially) optional, that someone hardcoded for the moment, and I wonder in what circumstances you would use a condition.

...roboticus

When your only tool is a hammer, all problems look like your thumb.

Update: Added code tags and changed "I wonder what the condition is where you'd put in a condition" to "I wonder in what circumstances you would use a condition" for clarity. (Thanks, AM)

what condition my condition is in?

In your initial example, I could see some merit in doing:

my $BigCalc = do {
    my $SmallCalc;
....
    $smallCalc;
};
[download]

But for the most part, the only occasions I've felt the need to use bare-blocks are:

• To limit the scope of locks on shared vars:

  { lock $fred; $fred = 3; }
  [download]

• For limiting the scope of closures:

  {
      my $var;
      sub fred {
          if( $var++ ) {
               ...;
          }
          ...
      }
  }
  [download]

  This use has mostly been superceded by state variables.

In neither case have I felt the need to introduce the opening brace in any way. Indeed, I think to do so would be more rather than less likely confusing; potentially flattering to deceive that the use of the construct was more important than it is.

Indeed, the post was motivated by "limiting the scope of closures".

A bare block is perfectly clear. It creates a limiting scope.

The BLOCK: block almost implies a loop, which it is, but that is not the intent. On the other hand, a more descriptive label like SCOPING_BLOCK: may work.

The do block by itself seems to be begging for while modifier. Assigning to a variable helps:

my $BigCalc = do {
    my $SmallCalc;
    ...
    f($SmallCalc);
};
[download]

The if block looks like debugging code. Someone commented out a chunk of code with if (0) {...} then turned it back on.

I prefer the classic™ #-annotation style ;-) Something along

{ #-------------------  classic annotation style  ------------
    my $x = 5;
    print "small calc $x\n";
} #-----------------------------------------------------------
[download]