I couldn’t agree more. One of my pet abominations is code like this:

if ($i != $j)
{
    # not equal
}
else
{
    # not not equal -- huh?
}
[download]

which can so easily be recast as:

if ($i == $j)
{
    # equal
}
else
{
    # not equal
}
[download]

So, let’s propose a general style guideline:

Thou shalt not code in double negatives.

For an amusing commentary on this theme, see Re^2: Can't remove directory-Permission denied (knot).

And for the one legitimate exception to the rule (that I can think of offhand), see Secret Perl Operators: the boolean list squash operator, x!!.

Sorry, I'm not buying. This is not ok? --

if ( $value != $expected_value )
{
    $errorcount++;
    die new Exception msg => "argh!";
}
else
{
     # continue with the happy path
}
[download]

But this is ok? --

if ( $value != $expected_value )
{
    $errorcount++;
    die new Exception msg => "argh!";
}
# continue with the happy path
[download]

no, no, no.

I reckon we are the only monastery ever to have a dungeon stuffed with 16,000 zombies.

Well, in

if (...)
{
    die ...;
}
else
{
    # continue with the happy path
}
[download]

the provision of an else block is redundant, since it suggests (misleadingly) that the code can somehow die and yet still resume execution following the else — which it can’t.

For this case, I would prefer:

unless ($value == $expected_value)
{
    $errorcount++;
    die new Exception msg => "argh!";
}

# continue with the happy path
[download]

which reads more naturally (to my ear). (Note that the original objection was not to unless, but to unless ... else.)

Update: Nice use of the <abbr> tag, BTW — I’ve learnt something new, could come in handy.  :-)

Athanasius <°(((>< contra mundum

You assume the order of the code blocks does not matter, too most ppl it does.

Either:
if ($i != $j)
or:
unless($i == $j)
[download]

Chose one, these are the same. Your example changes much more than just removing a double negative.