topic Re: The Boneheaded Code Thread in BreakPoint

The Boneheaded Code Thread

SteveChandler — Mon, 16 Apr 2012 22:32:52 GMT

Sometimes there is a very clear cause to a problem but it is so obvious that I just don't see it. Sort of like looking all over the place for your glasses when they are on top of your head.

Let's put our boneheaded mistakes in this thread. Don't give away the problem and let others report how long it took to spot the issue with a fresh pair of eyes.

I have a large project with many classes and many queues. I spent an hour trying to debug an "issue" where one of my loops would keep iterating after a dequeue operation. I tried to find what was enqueuing to it by running the Desktop Execution Trace Toolkit. The strangest thing - DETT reported a single enqueue yet the loop kept initializing my device over and over again. I closed LabVIEW and rebooted. Same problem. I was just about to file a bug report (could it have to do with the large number of queues in my application?) when I spotted the problem.

How long does it take you to see the problem in this example which demonstrates the nature of the problem? It took me an hour - Doh! And my application has dozens of queues so it's not like I don't know how to use them.

Re: The Boneheaded Code Thread

Andrey_Dmitriev — Mon, 16 Apr 2012 22:50:52 GMT

Dequeue Element should be placed inside of while loop (I mean second loop). Isn't?

Re: The Boneheaded Code Thread

SteveChandler — Mon, 16 Apr 2012 23:03:13 GMT

Yup. And I'll bet it just jumped right out at you too. What's the LabVIEW word for typo?

This one got me a long time ago.

Re: The Boneheaded Code Thread

Intaris — Tue, 17 Apr 2012 06:43:57 GMT

The dequeue and the fact that you're sending "Init" instead of "Initialize" as a command string.....

Re: The Boneheaded Code Thread

drjdpowell — Tue, 17 Apr 2012 08:38:05 GMT

@Steve Chandler wrote:

How long does it take you to see the problem in this example which demonstrates the nature of the problem?

15 seconds. But knowing the problem is obvious means you look for the obvious. I spent a large amount of time on a bug that was staring at me just recently. I had a polymorphic VI that I removed one instance from, and LabVIEW automatically substituted another instance with the same connector pattern. Obviously different icon, but I stared and stared at it and didn't notice. The original VI was "Wait till this actor (loop) receives the shutdown message" and the replacement was "Send this actor the shutdowm message", which has a rather different effect. I spent over an hour trying to track down who was sending the shutdown message to my actor before noticing.

Re: The Boneheaded Code Thread

JÞB — Tue, 17 Apr 2012 12:59:19 GMT

I have to admit. it took me longer to swap between full and mobile than to spot the loop invariant init.

Re: The Boneheaded Code Thread

SteveChandler — Tue, 17 Apr 2012 14:47:13 GMT

@Intaris wrote:

The dequeue and the fact that you're sending "Init" instead of "Initialize" as a command string.....

How ironic. I whipped up an example to show my "loop invariant init" and the example had another.... what's the word for typo in LabVIEW... (Although in this case it is in fact just a typo)

Re: The Boneheaded Code Thread

JÞB — Tue, 17 Apr 2012 17:44:08 GMT

@Steve Chandler wrote:

@Intaris wrote:

The dequeue and the fact that you're sending "Init" instead of "Initialize" as a command string.....

How ironic. I whipped up an example to show my "loop invariant init" and the example had another.... what's the word for typo in LabVIEW... (Although in this case it is in fact just a typo)

I had just assumed that was one of your space-saving strings---- go with that That's your story- stick to it

Re: The Boneheaded Code Thread

JÞB — Tue, 17 Apr 2012 20:45:19 GMT

I wanted to come back and thatnk you for posting this. I was a great opportunity to show around the shop! EVERYONE now has show constant folding of wires ON, they know what the squiggly wires mean and they realize how useful that info can be.

Aside- I've had those squiggly lines on for so long that I usually know which wires will squiggle as I sling them- so when I look at other code ("Hey! Jeff! What's going on with my code?") It looks funny without the constant wires squggled. Guess what would have saved you an hour?

Re: The Boneheaded Code Thread

Ben — Wed, 18 Apr 2012 12:34:51 GMT

Oh boy!

A thread comparing boneheaded code developers. I think i can compete in that sandbox.

In this thread, Dennis helped me figure out why* I could not increment a control at run-time.

"I got better" since then.

Ben

Yes, it was disabled.

Re: The Boneheaded Code Thread

SteveChandler — Wed, 18 Apr 2012 13:58:39 GMT

Kudos Ben! That is the spirit I had in mind for this thread. If this were a book a good title might be "Brave Confessions of the Brain Dead Software Engineer"

Let's keep 'em coming!

Re: The Boneheaded Code Thread

JÞB — Wed, 18 Apr 2012 18:20:53 GMT

OK I'll play too.

Task: Jeff quick set up a vi to cycle a temperature chamber up and down all night with this recording device in the chamber. We want to make sure these production prototypes do what they are supposed to do (Shut off when either too hot or too cold). You have 30 Minutes to set up.

Here is a simplified recreation.

We learned the plastic melts at 137C

The AND is bad!!! shouldn't that be an OR?I've since learned how to use In Range And Coerce

Re: The Boneheaded Code Thread

drjdpowell — Wed, 18 Apr 2012 21:16:13 GMT

I must have had a hundred bugs that were due to me reversing the True and False cases, or using Less Than when I should have used Greater Than. Almost seems like I do it wrong more than 50% of the time.

Re: The Boneheaded Code Thread

crossrulz — Thu, 19 Apr 2012 15:05:04 GMT

Yeah, I've been there Jeff. My recent boneheaded mistake was checking to see if an element want found in an array (Search 1D Array) and set the comparison to >0. It took me awhile before I realized that it's >=0.

Re: The Boneheaded Code Thread

SnowMule — Thu, 19 Apr 2012 16:56:51 GMT

@drjdpowell wrote:

I must have had a hundred bugs that were due to me reversing the True and False cases, or using Less Than when I should have used Greater Than. Almost seems like I do it wrong more than 50% of the time.

They're like USB connectors. 50% chance of getting it in the right way the first time, and 80% of the time you get it wrong.

Re: The Boneheaded Code Thread

DianeS — Thu, 19 Apr 2012 17:36:40 GMT

Odd...I find that if I have a 50% chance of getting it right, I have a 100% chance of getting it wrong.

SnowMule is either smarter or luckier than I am.

Re: The Boneheaded Code Thread

Thoric — Fri, 20 Apr 2012 13:46:38 GMT

Also, you're not subtracting the step from the previous value, but the previous value from the step? This means on the first attempt to reverse direction you end up with a negative temperature (once you fix the boolean logic error)?

Re: The Boneheaded Code Thread

JÞB — Fri, 20 Apr 2012 14:08:28 GMT

@Thoric wrote:

Also, you're not subtracting the step from the previous value, but the previous value from the step? This means on the first attempt to reverse direction you end up with a negative temperature (once you fix the boolean logic error)?

go figure! recreate a bonehead mistake and make another!

Re: The Boneheaded Code Thread

GregFreeman — Wed, 09 May 2012 16:04:07 GMT

In benckmarking code, why the @#$@#$!#$!#$!#$!#$!#$ ~~won't my two sums come out the same~~ do my two sums SOMETIMES come out the same:headbang:

Re: The Boneheaded Code Thread

altenbach — Wed, 09 May 2012 16:14:50 GMT

Just looking at the picture, they will be the same if you have fewer than 256 matches. 😄