Comment On A Great Gallimaufry of Goofiness

Well, I don't know Perl, but sendmail is returning a boolean depending on the success of the call. If it fails (returns false), the code then calls fail (it's in the same shortcut conditional expression) which sets a variable called $failed to false. Why not just check what sendmail is returning?

Cheers, Julian

(0 == DblSpread)

I've heard of some programmers (mostly coming from a VB background) who do this as a matter of practice, because if you type

(DblSpread == 0)

there's a slight chance you might accidentally type

(DblSpread = 0)

And introduce bugs that are extremely hard to find. If you accidentally type

(0 = DblSpread)

then compilers will complain about trying to assign a value to a constant. So they always put the constant on the left when doing a comparison. I don't necessarily like this syntax, but I can see why some people use it.

Duplicating the same comparison twice in an OR statement is a (mild) WTF, though.

Alex Papadimoulis:

Here's a platform we don't see to often: XSL. Actually, that's a good thing. Nothing worse than putting all of your business logic in XML style sheets. Especially when it's written like this snippet from Shane Blake

<xsl:choose>

    <xsl:when test="$isValid!='true'">

       <xsl:attribute name="class">enabledDivxsl:attribute>

    xsl:when>

    <xsl:when test="$isValid!='true'">

        <xsl:attribute name="class">disabledDivxsl:attribute>

    xsl:when>

    <xsl:otherwise/>

xsl:choose>

Not sure if the $isValid!='true' being in twice is a typo or the WTF, but the approach is sound.  $isValid could have gotten into the stylesheet any number of ways--as the value of a node in the XML, as a parameter when the stylesheet was called, whatever.  All you're doing is saying "Display this page as a valid/invalid page".  Move along, no business logic to see here...

There's nothing wrong with putting the constant as the LH argument in an == conditional statement, and it's most definitely not mostly for folks from a VB background. It's recommended in a few very good general programming books and it can indeed save your ass from a lot of hair pulling (which can be very painful).

I've wasted enough time debugging my own code where an intended == had been typed as = because of my long nails and unresponsive keyboard. Once you shake the habit of listing operands in the ordinary order, it's a time saver.

Jehos:

Not sure if the $isValid!='true' being in twice is a typo or the WTF, but the approach is sound.

I'm not completely sure, but doesn't XSLT have some kind of if..then..else?  The choose..when..otherwise is overkill for this job.

Jehos:

Alex Papadimoulis:

<xsl:choose>

    <xsl:when test="$isValid!='true'">

       <xsl:attribute name="class">enabledDivxsl:attribute>

    xsl:when>

    <xsl:when test="$isValid!='true'">

        <xsl:attribute name="class">disabledDivxsl:attribute>

    xsl:when>

    <xsl:otherwise/>

xsl:choose>

Not sure if the $isValid!='true' being in twice is a typo or the WTF, but the approach is sound.  $isValid could have gotten into the stylesheet any number of ways--as the value of a node in the XML, as a parameter when the stylesheet was called, whatever.  All you're doing is saying "Display this page as a valid/invalid page".  Move along, no business logic to see here...

Huh?

If $isValid = 'true', then the element never gets a class attribute. Though, I suspect the "enabledDiv" CSS class is just setting the element to have its default properties ("color: black;"), which is why this was never caught. Not a major WTF, but still a WTF.

For the first case, they probably meant to put test="$isValid='true'", but there's a minor WTF if $isValid is empty (the parameter wasn't passed in, there's no such attribute in the current node). In that case, both of the xsl:when tests would evaluate to false. Better to use test="$isValid='true'" and test="not($isValid='true')".

Also, I think some angle brackets got lost when this was posted. The code as presented is definitely not well-formed.

loneprogrammer:

Jehos:

Not sure if the $isValid!='true' being in twice is a typo or the WTF, but the approach is sound.

I'm not completely sure, but doesn't XSLT have some kind of if..then..else?  The choose..when..otherwise is overkill for this job.

There is an xsl:if, but unfortunately, there is no xsl:else. The only way to mimic the if/else statement in XSL is the choose/when/otherwise structure.

A Wizard A True Star:

Also, I think some angle brackets got lost when this was posted. The code as presented is definitely not well-formed.

Sorry, I looked again, and the code in Alex's original post is fine. It just somehow got messed up in the quoting.

rogthefrog:

There's nothing wrong with putting the
constant as the LH argument in an == conditional statement, and it's
most definitely not mostly for folks from a VB background. It's
recommended in a few very good general programming books and it can
indeed save your ass from a lot of hair pulling (which can be very
painful).

rogthefrog:

There's nothing wrong with putting the
constant as the LH argument in an == conditional statement, and it's
most definitely not mostly for folks from a VB background. It's
recommended in a few very good general programming books and it can
indeed save your ass from a lot of hair pulling (which can be very
painful).

I've wasted enough time debugging my own code where an intended ==
had been typed as = because of my long nails and unresponsive keyboard.
Once you shake the habit of listing operands in the ordinary order,
it's a time saver.

A Wizard A True Star:

(0 == DblSpread)

I've heard of some programmers (mostly coming from a VB background) who do this as a matter of practice, because if you type

(DblSpread == 0)

there's a slight chance you might accidentally type

(DblSpread = 0)

And introduce bugs that are extremely hard to find. If you accidentally type

(0 = DblSpread)

then compilers will complain about trying to assign a value to a constant. So they always put the constant on the left when doing a comparison. I don't necessarily like this syntax, but I can see why some people use it.

Duplicating the same comparison twice in an OR statement is a (mild) WTF, though.

Actually, your slam on VB'ers isn't kosher here. It's not a VB thing to do the (0 == DblSpread), that's an old C thing, and probably around for a lot longer than C. I guarantee that equality checks of that order are in most corporate coding standards documents.

Actually I wouldn't be too quick to write off stuff like this as a WTF:

Alex Papadimoulis:

if (connected || !connected)

{

  //ED: Snip

}

Sometimes I'll do this intentionally when I want to try turn an 'if' into an 'always' and see what happens with a block of code. Of course, things get messy when you come back to it two months later and have no idea why you did it.

Anonymous:

Why not just check what sendmail is returning?

Anonymous:

This technique probably saved bugs for
people using C/C++, but many newer languages require that the if
condition only be a boolean. So if you try to put an assignment (single
= sign) in an if condition, the compiler will complain, pretty much
getting rid of this class of bug.

A Wizard A True Star:

(0 == DblSpread)

I've heard of some programmers (mostly coming from a VB background) who do this as a matter of practice, because if you type

(DblSpread == 0)

there's a slight chance you might accidentally type

(DblSpread = 0)

And introduce bugs that are extremely hard to find. If you accidentally type

(0 = DblSpread)

then compilers will complain about trying to assign a value to a constant. So they always put the constant on the left when doing a comparison. I don't necessarily like this syntax, but I can see why some people use it.

Duplicating the same comparison twice in an OR statement is a (mild) WTF, though.

 

Anonymous:

rogthefrog:

There's nothing wrong with putting the constant as the LH argument in an == conditional statement, and it's most definitely not mostly for folks from a VB background. It's recommended in a few very good general programming books and it can indeed save your ass from a lot of hair pulling (which can be very painful).

I've wasted enough time debugging my own code where an intended == had been typed as = because of my long nails and unresponsive keyboard. Once you shake the habit of listing operands in the ordinary order, it's a time saver.

This technique probably saved bugs for people using C/C++, but many newer languages require that the if condition only be a boolean. So if you try to put an assignment (single = sign) in an if condition, the compiler will complain, pretty much getting rid of this class of bug.

Many, but not all. PHP doesn't and that's what I use most of the time. IIRC there isn't necessarily consistency in the semantics of the assignment operation. In most cases I know of, the assignment operation's return value is the value that's assigned, which lets you do things like

while ( (f = fgets(whatever)) != EOF) { do stuff }

because (f = fgets(whatever)) evaluates to fgets(whatever)

but I think some systems actually return true or false, i.e. whether the assignment operation succeeded, which is true almost all the time. So you don't want to rely on that. :(

I try to put the constant on the left in my == statements because it's no less readable than the usual way and it's just a good defensive programming practice. Defensive programming is a Good Thing when it's not totally out of control and you triple check every little thing.

Alex Papadimoulis:

Public Sub ResetCase(Optional ByVal bRestart As Boolean = False)

   If bRestart Then

      objUtils.ResetCase(bRestart)

   End If

End Sub

I bet this has something to do with how the UI is set up; perhaps a button that performs an action and a checkbox next to it that says "reset case".  The code probably looks something like this:

sub button_OnClick()

   ' do some VB crap bla bla bla

   ResetCase(checkbox.IsChecked)

end sub

That way, the button's event script doesn't need an IF statement to see if the checkbox is checked or not.  If that's the case, then it hits on one of my pet peeves -- mixing the UI logic with the business logic [:@]

rogthefrog:

There's nothing wrong with putting the
constant as the LH argument in an == conditional statement, and it's
most definitely not mostly for folks from a VB background. It's
recommended in a few very good general programming books and it can
indeed save your ass from a lot of hair pulling (which can be very
painful).

I've wasted enough time debugging my own code where an intended ==
had been typed as = because of my long nails and unresponsive keyboard.
Once you shake the habit of listing operands in the ordinary order,
it's a time saver.

A Wizard A True Star:

There is an xsl:if, but unfortunately, there is no xsl:else. The only way to mimic the if/else statement in XSL is the choose/when/otherwise structure.

Anonymous:

for what it's worth, gcc will moan about if (x = y) leading to the standard ObjC construct if ((self = [super init])) { } The nested braces turn the assignment into a boolean, basically, and get rid of the warning. With a decent compiler and -Werror -Wall, you're pretty much set, and 0 == foo becomes a thing of the past Simon

Sadly not everybody uses a compiled language.

As an aside, I'd like to have an optionally strongly-typed language that would give you all the advantages of loose typing (as in Perl, PHP, etc) with the added debugging ease afforded by strongly typed languages. For example everything could be loosely typed with implicit conversion of strings to numbers and such, except for those cases where you force a variable to have one type only, say with something like

assert int $a = 0;

If your program attempts to assign a non integer value to $a at any point (e.g. from a sql query with weird field to variable or array index mapping) the program would complain. You could extend that to objects with

assert MyClass $obj;

Then if you call a mysql_fetch_object and assign the result to $obj, and the structure of your db resultset isn't compatible with a MyClass object, the program would complain.

I can't count how many hours I've wasted debugging code just because a variable wasn't assigned what I expected it to be assigned but no error occurred because of a language's loose typing.

Anonymous:

Well, I don't know Perl, but sendmail is
returning a boolean depending on the success of the call. If it fails
(returns false), the code then calls fail (it's in the same shortcut
conditional expression) which sets a variable called $failed to false.
Why not just check what sendmail is returning?

Cheers, Julian

 

if ( sendmail(%email) )
  {
  ...
  }
else
  {
  ...
  }

But that's just a matter of style.  The other way is perfectly fine.

    dZ.

CornedBee:

The PERL thing should be written as in any other language, if you insist on a temporary:



$success = sendmail;

if($success) {

...



Using the weird &fail syntax obfuscates the correlation between the
value of $failed and the operation being performed, not least because
function calls don't require parentheses.

    do_the_deed() || fail_miserably();

Nevertheless, your post doesn't answer the crucial question of whether Larry Wall's wife is the mother of Perl.

rogthefrog:

mother of Perl

pjabbott:

Alex Papadimoulis:

Public Sub ResetCase(Optional ByVal bRestart As Boolean = False)
   If bRestart Then

      objUtils.ResetCase(bRestart)

   End If

End Sub

I
bet this has something to do with how the UI is set
up; perhaps a button that performs an action and a checkbox
next to it that says "reset case".  The code probably looks
something like this:

sub button_OnClick()

   ' do some VB crap bla bla bla

   ResetCase(checkbox.IsChecked)

end sub

That
way, the button's event script doesn't need an IF statement to see
if the checkbox is checked or not.  If that's the case, then it
hits on one of my pet peeves -- mixing the UI logic with the business
logic [:@]

Anonymous:

> (DblSpread == 0)

> there's a slight chance you might accidentally type

> (DblSpread = 0)

That's right. I've encountered this problem some time ago, while programming in both Pascal and C.

Just like The Last Bug:

while (1)

{

    int status = getRadarStatus();

    if (status = 1) launchNuclearMissiles();

}

Anonymous:

 That should never happen in Pascal, since Pascal uses := for assignment and = for equality.

C/C++/C#/Java are also have different operators '=' for assignment and '==' for equality check. The problem is that C and C++ allow treatment of integer results to be interpreted as "boolean" (everything which is not a 0 is true). In C# and Java this problem doesn't exist because they were "cured" from this disease and allow only boolean expressions in the 'if' statement.

i.e.

int a;

if (a = GetStatus()) //is valid in C/C++ (usually generates a warning)

to make the same trick in Java/C# you must type more :)

if ((a = GetStatus()) != 0) 

Pascal is more strict - it doesn't allow assignments inside if statement

i.e.

var a: Integer;

begin

a := GetStatus(); (* the is no way to make this assignment inside if*)

if a <> 0 then

Darrin:

That should never happen in Pascal, since Pascal uses := for assignment and = for equality.

rogthefrog:

Sadly not everybody uses a compiled language.

You don' t have to use a compiled language to be warned when you
accidentally assign instead of comparing. Take Ruby, for example:

rik@rikkus ~ > irb


irb(main):001:0> a=1


=> 1


irb(main):002:0> if (a=2)


irb(main):003:1> puts "it's 2"


irb(main):004:1> end


(irb):2: warning: found = in conditional, should be ==


it's 2


=> nil

Rik

Alex Papadimoulis:

<xsl:choose>

    <xsl:when test="$isValid!='true'">

       <xsl:attribute name="class">enabledDiv</xsl:attribute>

    </xsl:when>

    <xsl:when test="$isValid!='true'">

        <xsl:attribute name="class">disabledDiv</xsl:attribute>

    </xsl:when>

    <xsl:otherwise/>

</xsl:choose>

This should at least USE the <otherwise> element that is there [I]
<xsl:choose>
    <xsl:when test="$isValid='true'">
       <xsl:attribute name="class">enabledDiv</xsl:attribute>
    </xsl:when>
    <xsl:otherwise >
        <xsl:attribute name="class">disabledDiv</xsl:attribute>
    </xsl:otherwise>
  </xsl:choose>

enabledDiv and disabledDiv seem like generic names, maybe a $cssClassName would be a better variable to use.
You can assign it whereever it was that you set $isValid, then get rid of this additional condition and use.
<xsl:attribute name="class"><xsl:value-of select="$cssClassName"></xsl:attribute>

Anonymous:

Anonymous:

 That should never happen in Pascal, since Pascal uses := for assignment and = for equality.

C/C++/C#/Java are also have different operators '=' for assignment and '==' for equality check.

rogthefrog:

Anonymous:

for what it's worth, gcc will moan about if (x = y) leading to the standard ObjC construct if ((self = [super init])) { } The nested braces turn the assignment into a boolean, basically, and get rid of the warning. With a decent compiler and -Werror -Wall, you're pretty much set, and 0 == foo becomes a thing of the past Simon

Sadly not everybody uses a compiled language.

As an aside, I'd like to have an optionally strongly-typed language that would give you all the advantages of loose typing (as in Perl, PHP, etc) with the added debugging ease afforded by strongly typed languages. For example everything could be loosely typed with implicit conversion of strings to numbers and such, except for those cases where you force a variable to have one type only, say with something like

assert int $a = 0;

If your program attempts to assign a non integer value to $a at any point (e.g. from a sql query with weird field to variable or array index mapping) the program would complain. You could extend that to objects with

assert MyClass $obj;

Then if you call a mysql_fetch_object and assign the result to $obj, and the structure of your db resultset isn't compatible with a MyClass object, the program would complain.

I can't count how many hours I've wasted debugging code just because a variable wasn't assigned what I expected it to be assigned but no error occurred because of a language's loose typing.

Try Flash Actionscript 2.0. It behaves like that. If you specify a type when declaring the variabel it'll do typechecking(unless you assign the value of an "untyped" variable). But if you exclude the typedeclaratin it can be assigned just about anything.

Maurits:

but I actually think the code listed reads better: "sendmail mail or fail"

DZ-Jay:

I beg to differ.  Its only obfuscated to non-Perl weenies. 
In Perl, it is a matter of conventional style to use constructs of the
form:

    do_the_deed() || fail_miserably();

This is read as "do the deed or fail miserably", which follows a
semantic approach to code style. 

pjabbott:

I
bet this has something to do with how the UI is set
up; perhaps a button that performs an action and a checkbox
next to it that says "reset case".  The code probably looks
something like this:

sub button_OnClick()

   ' do some VB crap bla bla bla

   ResetCase(checkbox.IsChecked)

end sub

That
way, the button's event script doesn't need an IF statement to see
if the checkbox is checked or not.  If that's the case, then it
hits on one of my pet peeves -- mixing the UI logic with the business
logic [:@]

Schol-R-LEA:

In any case the actual WTF is that he is using a separate function to
set a global variable, with no gain in abstraction, while handling the
actual error logging inline.

Anonymous:

Darrin:

That should never happen
in Pascal, since Pascal uses := for assignment and = for
equality.

I mean after programming a lot in Pascal, I've made sometimes mistakes
like using = instead of == in the first few days of returning to C.

rogthefrog:

I try to put the constant on the left in my == statements because it's no less readable than the usual way and it's just a good defensive programming practice. Defensive programming is a Good Thing when it's not totally out of control and you triple check every little thing.

if (0 == someFunctionWithLongName (with, some + arguments (that, maybe, call), some, other (functions), and so (on) and so (on)) {

with:

if (someFunctionWithLongName (with, some + arguments (that, maybe, call), some, other (functions), and so (on) and so (on) == 0) {

In the second case you have to parse _whole_ statement to see what's compared with what.

I think readability is the most important criteria when you can write the relation either way. And the easier you can find operator the better readability.

Anonymous:

C/C++/C#/Java are also have different
operators '=' for assignment and '==' for equality check. The problem
is that C and C++ allow treatment of integer results to be
interpreted as "boolean" (everything which is not a 0 is
true). In C# and Java this problem doesn't exist because they
were "cured" from this disease and allow only boolean expressions
in the 'if' statement.

i.e.

int a;

if (a = GetStatus()) //is valid in C/C++ (usually generates a warning)

to make the same trick in Java/C# you must type more :)

if ((a = GetStatus()) != 0) 

Anonymous:

if (connected || !connected)

{

  //ED: Snip

}



This could potentially be understandable if 'connected' is of a triboolean type.

(e'g Boost's boost::tribool type which has an indeterminate value)