The Daily WTF: Curious Perversions in Information Technology

2007-01-26 Reply Admin

Unlike Java, in .NET there is no stack trace until it is thrown.

2007-01-26 Reply Admin

Betta Glurpse:
This is C#.
To all of you who think ==true makes stuff more readable:

...

Programmers should really, really, really, understand boolean logic and if statements. If they don't, there's a good chance there are other fundamentals they don't understand.

I think you're confusing readable and understandable. The original claims made here in favor of '==true' were based on being easier to read, and I think that (a) they ring true, and (b) who gets to be the judge of what others find more readable?

I know that these tired eyes have missed a '!' on more than one occasion, especially nested inside parens as mentioned here. In my 20+ years of programming, I've always tried to steer clear of the 'punctuation-style' operators when possible, as they DO slow down reading as opposed to more lengthy operators. Notice I again said "reading", not "understanding".

One of my "rules" developed over the years is to ALWAYS remember that code is usually "write once, read many". YMMV.

2007-01-26 Reply Admin

This site has gone downhill in the past couple months. I cant stand these watered down WTFs anymore.

captcha: stinky, like this site's recent content

2007-01-26 Reply Admin

When does rookie initiation take place?

2007-01-26 Reply Admin

Steve:
When does rookie initiation take place?

Duh... In the rookie initializer, or in the constructor of the enclosing class, of course :)

2007-01-26 Reply Admin

Holy excrement... why not use this method instead?

2007-01-26 Reply Admin

Bill:
I know that these tired eyes have missed a '!' on more than one occasion, especially nested inside parens as mentioned here.

Just use five or seven, !!!!!, then you can't miss'em (ok, just being funny here :-))

In my 20+ years of programming, I've always tried to steer clear of the 'punctuation-style' operators when possible, as they DO slow down reading as opposed to more lengthy operators. Notice I again said "reading", not "understanding".

I can follow your argument about punctiation-like constructs being harder to read. As an example, of the two corresponding constructs below, the foreach version is easily more readable even though it is more verbose:

foreach element in list          (C#)
for element : list             (Java)

My counterargument on the readability issue is that

if (!SelectionIsValid)

reads like plain English to me - "if not the selection is valid...", whereas

if (SelectionIsValid == false)

reads like wierd courtroom English ("if it is false that the selection is valid..."). While redundant syntax can help readability, you can also drown in it.

One of my "rules" developed over the years is to ALWAYS remember that code is usually "write once, read many". YMMV.

We agree on that one.

Bill:
I think you're confusing readable and understandable. The original claims made here in favor of '==true' were based on being easier to read, and I think that (a) they ring true, and (b) who gets to be the judge of what others find more readable?

Now for the part about understanding: Your stand on the readability of ==false versus ! is a conscious choice, having understood both ways. In my experience, that separates you from most of the ==false-proponents.

Why ==false gives away an unskilled programmer:I was an assistant teacher in beginners and intermediate programming courses at the university some years ago, and overwhelmingly, the students who felt the urge to add "== false" to their boolean expressions were the ones that didn't quite understand boolean logic. Because they weren't comfortable with the boolean logic, they felt that they somehow needed to spoon feed the compiler with verbose instructions: "now, compiler, you need to take that a==b-thing, and check whether it was false, ok?". It wasn't a conscious choice. They were the same students that didn't quite understand how to use loops, and wrote code like

StrutYourStuff();
while (theStuffWasStruttedRight == false)
{
StrutYourStuff();
}

and generally would write code much like in today's WTF.

Today I work with many skilled colleagues, and I rarely see such redundant "explanations" for the compiler. But quite recently I visited another project, with ==false redundancies sprinkled liberally around the code base. My alarm bells rang, and sure enough: The project had next to no automated test, loads of errors, loads of copy-paste-edited code, no documentation... Is it a coincidence? Naah!

So, basically, every experience I have ever had with coding has shown that ==false and WTFiness go hand in hand.

And just to finish off: Even if I cannot judge what others find more readable, I have a pretty good guess in this case (does the first statement even do what we want it to?):

if (a == b == false)
if (!( a == b))
if (a != b)

2007-01-26 Reply Admin

Betta Glurpse:

foreach element in list          (C#)
for element : list             (Java)

Whoops, forgot the parentheses. Should also have added them to that a == b == false thing to be fair.

2007-01-27 Reply Admin

Of course, in my opinion

if (a)

is the right way.

if (FALSE == a)

has one advantage above

if (a == FALSE)

in C/C++, the compiler won't allow you to do

if (FALSE = a)

but it will be quite content with

if (a = FALSE)

I have seen that WAY too often. And so hard to spot at times.

2007-01-27 Reply Admin

Bill:
Betta Glurpse:
This is C#.
To all of you who think ==true makes stuff more readable:

...

Programmers should really, really, really, understand boolean logic and if statements. If they don't, there's a good chance there are other fundamentals they don't understand.

I think you're confusing readable and understandable. The original claims made here in favor of '==true' were based on being easier to read, and I think that (a) they ring true, and (b) who gets to be the judge of what others find more readable?

I know that these tired eyes have missed a '!' on more than one occasion, especially nested inside parens as mentioned here. In my 20+ years of programming, I've always tried to steer clear of the 'punctuation-style' operators when possible, as they DO slow down reading as opposed to more lengthy operators. Notice I again said "reading", not "understanding".

One of my "rules" developed over the years is to ALWAYS remember that code is usually "write once, read many". YMMV.

Damn right, mate. Unfortunately, following this perfectly sensible rule would result in doom for 90% of the idiots who post answers here. And they're probably in the top 10% of softare professionals anyway.

Happy, happy, happy.

(Captcha: gotcha. Well, no, I'm afraid you'll have to try a little harder...)

2007-01-27 Reply Admin

gwenhwyfaer:
Fredric:
captcha: bathe, is that even a real word?

makes sure to stand a good six feet upwind of Fredric

...realising in dismay that the use of the term "upwind" is certain to provoke another interminable debate about whether it's correct... sigh

Yes, it's correct. End of thread.

PS Alex: WTF is "onomatopoeia"? Hell, I've got an A-Level in Ancient Greek, and even I find this one difficult to type in ..

2007-01-27 Reply Admin

snoofle:
n:
el jaybird:
Frzr:
atari, where you had no exceptions.

Shaka, when the walls fell.

YAYAYAAYY!!!! You made my day!

Temba, his arms wide.

(captcha -- xevious, one of my favorite old video games. I can still hum the theme song.)

Somewhat off topic, but...

you know you're getting old when you feel old because you get not only both of these references, but the original references that came (way) before them..

Getting references to the epic of Gilgamesh. Now that's old!

2007-01-27 Reply Admin

So are you so stupid or am i so smart that i think it's perfectly readable without that "== bool"? Maybe poeple who need this only think they know the language. There's more to it. There is no spoon...

2007-01-27 Reply Admin

Damn, this was a reply. The forum really is the biggest wtf.

BAReFOOt:
AndrewB:
Smudge:
Whenever I see "== true" or "== false", it's always a guarantee that the rest of the code will be awful too. This one didn't disappoint,

Ever heard of readability?

So are you so stupid or am i so smart that i think it's perfectly readable without that "== bool"? Maybe poeple who need this only think they know the language. There's more to it. There is no spoon...

2007-01-28 Reply Admin

PS Alex: WTF is "onomatopoeia"? Hell, I've got an A-Level in Ancient Greek, and even I find this one difficult to type in ..

http://en.wikipedia.org/wiki/Onomatopoeia

2007-01-28 Reply Admin

AndrewB:
Smudge:
Whenever I see "== true" or "== false", it's always a guarantee that the rest of the code will be awful too. This one didn't disappoint,

Ever heard of readability?

Yes, I have heard of readability.

...Oops. According to your version of "readability", that should be:

"Yes, it is true that I have heard of readability."

Sheesh.

Earl Purple · 2007-01-29 Reply Admin

Anders:
Smudge:
Whenever I see "== true" or "== false", it's always a guarantee that the rest of the code will be awful too. This one didn't disappoint,

In the type of languages as C#, sure. But if you're programming general-purpose C and similiar languages there's a point of doing == TRUE and == FALSE. I've seen systems where TRUE is 0 and FALSE is 1 and you'd be suprised how interesting problems you can get when someone think they can just do if (a) and if (!a) as "normal".

There are no such "systems" only bad programmers if they make FALSE to mean non-zero and TRUE to mean zero, just like writing a class where read() means write and write() means read. It will compile but won't work the way the user expects it to and will therefore be wrong.

In C and C++, boolean expressions are true if non-zero and false if 0, so comparing to false is ok (albeit bad style but comparing to true is wrong because true could be 1, -1 or a bit-mask etc and it is not guaranteed that one true value is equal to another.

Comparing a pointer to NULL (or 0) or a return value to 0 is another matter. It is probably good style here. It is bad style in my opinion to compare strings in C with a statement such as

if ( !strcmp( str1, str2 ) )

because of the quirk of strcmp that it returns 0 if the strings are the same and non-zero if they are different (<0 or >0 according to ordering). Better to say

if ( strcmp( str1, str2 ) == 0 )

(note it won't compile if you put = 0 here as the return of strcmp is not an l-value)

Note also that an overloaded operator == or != in C++ is not guaranteed to be defined both ways so

if ( 0 != obj )

is not guaranteed to be defined at all just because you can do

if ( obj != 0 )

Now for the original post, something strange I noticed was that the coder was doing a foreach loop and didn't use the loop object (match) which seems rather strange to me.

2007-01-29 Reply Admin

In C#,

if(someValue)

and

if(!someValue)

looks better than

if(someValue == true)

and

if(someValue == false)

That's just me.

2007-01-29 Reply Admin

[quote user="Jackal von ÖRF"][quote user="EvanED"][quote user="htg"]However it is less CPU overhead than executing code in a try..catch statement (well, historically in Java, I don't know about now, or C#).[/quote]

That depends on the implementation, and how often exceptions are thrown. I don't know how Java or C# does it, but it's possible (and I think at least sometimes done) to compile exceptions in such a way that if an exception isn't thrown there is NO overhead...

The overhead of try-catch blocks, when not throwing exceptions, should be a problem only when the try-catch is inside a loop/hotspot. The overhead is in entering/exiting the try-catch block, and not in running code inside the block.

Quoted from http://www.mortench.net/blog/2006/08/08/dos-and-donts-for-exception-handling-or-what-every-developer-should-know-about-the-implementation-of-exception-handling/ "Specifically, the case of overhead of try-catch-finally constructions when no exceptions occur is difficult to get rid of by compiler & virtual-machine implementers. [--] Basically this is because something like a “linked list” has to be maintained internally by the compiler or VM each time the control flow enters or exits a try-catch-finally."[/quote]

I'm not sure if that information is correct. It's possible that some JITs for Java compile code in a way that requires maintaining some overhead data structure when entering and exiting try/catch blocks, but in interpreted code this would not be necessary since the method has a table relating sections of the bytecode to catch blocks. As long as the JITted code could map offsets in the native code back to the bytecode it was compiled from, it could use this table, and thus would not have to maintain any further data structure.

At least the Sun JVM on 32-bit Windows seems to do this. I haven't had a chance to try any other architecture yet. I created a class that adds up some numbers in a loop, parsing them all from Strings with Integer.parseInt() (but they're all good, so no exceptions will be thrown). It doesn't matter whether I have a try/catch block for NumberFormatException in the inner loop, the running time for one million iterations is the same.

It would be interesting to hear if this actually is a problem on other JVM's, or other architectures.

2007-02-01 Reply Admin

I am not that expert at it as some of you guys are but I can see why someone would want some functions to return an exception like that. Perhaps in situation of a network connection where you are remotely executing some function on the server and wanted to make sure that no exceptions were thrown.

2007-02-05 Reply Admin

pndeukab gnsz qseygox iugoprvt wkdalfoe ylni knfmjstyo

2008-09-22 Reply Admin

Hah I don't blame the guy, trying and catching it such a pain compared to just returning a success indicator of some kind.

2009-02-23 Reply Admin

AndrewB:
Ever heard of readability?

Absolutely. And I also know that "if (...)" and "while (...)" expect boolean expressions. Hint: Comparing a boolean variable to 'true'/'false' doesn't make it more boolean.

I find "if (a && b)" quite readable. Quick: Tell me when which branch of the following conditional will be taken:

if (! (a != true && b == !false))

I wish the programmer had just written

if (a || b)

In everyday language, do you say "If it's true that I carry an umbrella, then it's not going to rain?" Just say what you mean: "If I carry an umbrella, it's not going to rain."

"...== false" is a hint that the programmer never understood that Boolean is an algebra, and that he can simply write things like

bool ok = ((0 < x) && (x < 10));

Now if he didn't get that, what else did he miss?

Of course, when dealing with numbers instead of boolean, I'd insist on a comparison. A number or a pointer value is not boolean by concept, so I want to see

if (u > 0) /* assuming unsigned u; */

if (p != NULL) /* assuming p is a pointer */

The C interpretation "zero is false, non-zero is true" is not obvious.

2013-05-29 Reply Admin

This is probably obvious, but what about Java's Throwable.getCause()?

Not that most people would be implementing that, of course...

Catch and Release

Leave a comment on “Catch and Release”