I need to ensure that a variable is decremented regardless of how an if clause is exited,

Then do the decrement before entering the if:

...
--$loop;
if( condition1 ) { {
  
    ...
    last if condition2; 
    ...
} }
[download]

That'll break the program's logic; $loop may only be decremented within the conditional (otherwise, yes, I'd put it outside of it).

That'll break the program's logic; $loop may only be decremented within the conditional (otherwise, yes, I'd put it outside of it).

I that case, decrement it as the first thing in the conditional, then you're guaranteed it'll happen.

The point is that, as described, there is no reason to employed contorted logic to achieve the described requirement.

Perhaps in an attempt to simplify the original code you've omitted something that makes the contorted logic necessary, but as posted, it simply isn't needed.

---

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

To me the secret to DRY (which is Do not Repeat Yourself -- I had to look that up) is to convert functionality to functions, encapsulate it in objects as methods that only execute in certain states, or to utilize some core language feature to reduce the code.

From your desire, "I need to ensure that a variable is decremented regardless of how an if clause is exited.." it reads like you want the decrement operation to happen automatically when something else occurs -- a form of encapsulation -- like this:

use strict;

my $g_var = 1_000;

sub special_dec {
    my $choice = shift;
    if  ($choice)
    {
        --$g_var;
    }
}

my $thing = 'dog';

if ( $thing eq 'cat')
{
    my $cntr = 0;
    while (++$cntr < 11) {
         last if (special_dec(900==900));
    }
}
elsif ($thing eq 'dog')
{
    my $cntr = 0;
    while (++$cntr < 11) {
         last if (special_dec(900==900));
    }

}
print $g_var;
1;
# of course prints 999
[download]

Now you don't have to think about manually decrementing or handling $g_var, something else does that for you.

Refactoring your solution may mean that you really need to write special operations that allow you to iterate over lists and handle certain internal values without the user of that object having to consciously know about them. I think in Perl there is a desire to try and solve a great many problems using language constructs and coding techniques when oftentimes the more obvious solution is to just push certain actions into functions or object methods instead. If you are doing Perl golf then disregard this post but your question doesn't read like that.

Sure, something like Scope::Guard would do the trick as well, but these approaches can be a mighty big sledgehammer when you're trying to swat a misquito. Yes, they do work, but...

I don't see anything wrong with using built in language constructs if they're not golf-like. I don't consider adding an extra block within the if clause to be golf-like, but I acknowledge that tastes do vary.

I don't get it

while( ... )
{
  --$loop;
  ...
}
[download]

The repeated decrements are not DRY.

DRY doesn't apply to match

But no matter how many exit-points you have, the entry-point is always the same. So why don't you decrement there after the first if ?

$loop is used in the conditional, so if I decremented it first, I'd have to add one to it everywhere it is being used.

> $loop is used in the conditional, so if I decremented it first,...

Unclear.

None of your examples have $loop in the conditional and I suggested decrementing it after not before !

Please explain what's different here

if ( $condition1 ) {

  ...

  unless( $condition2 ) {

  ...

  }
  --$loop;                # common exit point
}
[download]

Cheers Rolf

(addicted to the Perl Programming Language)

Whoops. Forgot to log in. The above comment is mine.

Here's a completely different approach as a self-contained program for quick testing.

( The Getopt::Long::Configure isn't necessary here, but I personally use it whenever I'm using Getopt::Long as programs tend to grow to where I'd want it. )

#!/usr/bin/perl
use strict;
use warnings;
use Getopt::Long ();

my %opt = ( 'do-stuff' => 0, 'do-more' => 0 );

Getopt::Long::Configure( 'gnu_getopt' );
Getopt::Long::GetOptions( \%opt, 'do-stuff+', 'do-more+' );

my $counter = 1;

if ( $opt{ 'do-stuff' } ) {
    my @stuff_to_do = ( sub { print "some stuff\n"; } );
    push @stuff_to_do, sub { print "some more stuff\n"; } if $opt{ 'do
+-more' };

    for my $s ( @stuff_to_do ) {
        $s->();
    }
    $counter--;
}

print "$counter\n";
[download]

Agree ... this is the sort of code that I shudder to see, and see a lot.   Because of the way such code is constructed, it is difficult to “see” the conditions under which a particular bit of code might be executed.   Therefore, it is difficult to predict what conditions might actually prevail when a particular bit of (buggy) code is actually executing.   It is also difficult to locate all of the places where the value of a particular variable, such as $loop, is being manipulated, and to be certain that every single one of them is correct and that the entire set is complete.   When we harped at an entire generation of coders-to-be, “don’t use goto,” what I really think that we were trying to say is, “don’t be hard-to-follow or hard-to-predict.”

Your comments are interesting, valid, and therefore, appreciated.   But when I encounter code like this, I usually have someone rewrite (“refactor” is the buzzword these days) the code and to write a bunch of tests to prove what it does, before and after.   And, if you look at such “monstrosities” long enough, you almost-inevitably find One More Bug™, or even, This Bug Is The Business Truth.™

Refining what InfiniteSilence said and applying to the OP examples, I'd go with:

sub part0 { ... }
sub part1 { ... }
if ( $condition1 ) {
  {
    part0();
    last if $condition2;
    part1();
  }
  --$loop;
}
[download]

Then all of the condition and decrement logic is, visually, close together, so easier to understand.