The Weird and The Wonderful

The Weird and The Wonderful forum is a place to post Coding Horrors,
Worst Practices, and the occasional flash of brilliance.

We all come across code that simply boggles the mind. Lazy kludges, embarrassing mistakes, horrid
workarounds and developers just not quite getting it. And then somedays we come across - or write -
the truly sublime.

Post your Best, your worst, and your most interesting. But please - no
programming questions . This forum is purely for amusement and discussions on code snippets. All
actual programming questions will be removed.

If you display a lot of pictures at once, then the system becomes just as annoying to users as a captcha.

Also, you'd have to maintain a large and constantly-changing database of pictures to keep the bot from memorizing which pictures are the vehicles.

In any case, defeating the bots is a much bigger task than people realize. If bot writers are willing to create advanced algorithms capable of deciphering a captcha, then they are willing to go to great lengths to defeat other security features, too.

I've seen that with "Kittens" and "Puppies" as well - very damn annoying!

Those who fail to learn history are doomed to repeat it. --- George Santayana (December 16, 1863 – September 26, 1952)
Those who fail to clear history are doomed to explain it. --- OriginalGriff (February 24, 1959 – ∞)

Thanks, I'll try that too and maybe do some performance comparisons. Performance really isn't an issue with my current usage -- about forty elements being checked with a predicate provided on the command-line.

I wish it was that easy. But X++ does not have overrides, the Dynamics Ax VM creates SQL statements from this code.
By tracing statements in the SQL Server I may be able to see the different statements created, but the bottom line is, that this should be a very very simple comparison, and having a failure here, gives me the creeps.

"God doesn't play dice" - Albert Einstein

"God not only plays dice, He sometimes throws the dices where they cannot be seen" - Niels Bohr

Ha!
I found the problem. DAX uses a caching mechanism to avoid too many roundtrips to the SQL Server.
If you're using the primary key in a query, then DAX will search an in-memory cache to retrieve a single record.
Apparently, DAX gets confused when I use the primary key field busRelAccount on the left hand side of the comparison. Using bus.disableCache(true) fixes this problem.
I hope they get rid of this bug soon, I really don't like to think of all the places I could have trusted this to just work.

"God doesn't play dice" - Albert Einstein

"God not only plays dice, He sometimes throws the dices where they cannot be seen" - Niels Bohr

It's not horrible, but it's pretty representative for the code as a whole.
A lot of redundancy, a lot of global variables, no null values (but still NullReferenceExceptions...), Forms with 1000+ lines of code, etc.

Or did you want to tell us that it's better to do the comparison of OrderNumber to 0 whenever that IsNew function is used? Oh no! That would deserve to be posted here! IsNew clearly tells you the intention of the code, while If(OrderNumber=0) does not.

It is a function on the Order class, but it still takes a parameter (it just gets mOrderNumber given to it every time).
VB does not have a ternary operator.

I'm saying the function could look like this:Return OrderNumber = 0
There is no need for an IIF anywhere in the code. As I said, it's not truly horrible, but it's an 'interesting' way to return if OrderNumber = 0

Been a while since I've made the computer hiccup, but last week had an interesting experience. A bug evidently caused everything to start paging to disk on Win7-64.

The short of it was in a window resizing routine the DC wasn't released correctly, so memory was being eaten quickly. Didn't realize it and continually resized for multi-seconds for fun. The computer started getting sluggish as heck. Opened up Resource Monitor and noted the memory increase upon resizing. But it was too late.

At bootup about 2 gigs is taken by all the background stuff I use. With the other progs, and the leak, my 4 Gigs main memory was exceeded. All well and good, but then the unexpected occurred: I watched the resource monitor show my memory opening up to the state where it only reported 560 MB or so being used! But none of the programs I had open closed at that point. They were VERY slow to respond, though!

A reboot fixed everything, and the bug was squashed in the next round. That's my tale. It fits the weird, but not the wonderful. For that you can have this piece of classic code I came upon in the project, which I just massively revised:

Rect() {
Rect(0, 0, 0, 0);
}

That initializer wasn't doing what the original author thought it was doing...

If it is expanded, Visual Studio throws a bunch of "103 IntelliSense: '#' not expected here" errors. I don't think they ever #defined DEBUG in their code, so the asserts were never even used. I guess they just liked typing... (Or maybe VS6 expanded macros differently?)