Rube Goldberg Code

[altenbach]

Haven't seen these boolean NOOPs for at least a few hours :o, but sometimes they come in swarms. 😄

(seen here)

[billko]

---

@altenbach wrote:

Haven't seen these boolean NOOPs for at least a few hours :o, but sometimes they come in swarms. 😄

(seen here)

---

There actually is a case where I would compare a Boolean to a Boolean (wire).  That would be if there is a requirement that states you need to check it against a Boolean value - and then the Boolean becomes P/F not T/F.  A subtle variation of this is if you are checking two clusters for equality.  If one of the elements compared happens to be a Boolean data type, you can't avoid the comparison.

[wiebe@CARYA]

---

@altenbach wrote:

Haven't seen these boolean NOOPs for at least a few hours :o, but sometimes they come in swarms. 😄

(seen here)

---

It could make some sense during testing. Forcing the bottom item to be true with one click to test might be useful if you have to switch this a lot to test. Same for the selector. If you understand this trick you probably don't need to use it very often.

Also, if you are smart enough to apply this trick for testing, you should be smart enough to remove it when posting it or using it in production code. Or be prepared to lose some credit...

[wiebe@CARYA]

Can't resist:

There are 10 kinds of people, those work understand binary and those who don't.

[altenbach]

---

wiebe@CARYA wrote:
It could make some sense during testing. Forcing the bottom item to be true with one click to test might be useful if you have to switch this a lot to test. Same for the selector. If you understand this trick you probably don't need to use it very often.

---

There is nothing wrong adding a few injection points for debugging (I typically insert a control so I can actually change it during the test run), but the bottom (B) is not suitable for this, because you e.g. cannot force the result to be FALSE (you could add an "AND" with yet another diagram constant, but then the truth table becomes a bit convoluted). OTOH, the upper code can give all the possible outcomes (direct, always false, always true, flip) by changing the constants during debugging. But yes, leaving this code in is very dangerous, because it might be hard to remember what the natural states of the constants should be. Even remembering to always revert them might be hard.

Of course the "testing" argument  would no longer be valid if we had this old idea implemented. 😄

[altenbach]

Look at all these local variables! (seen here)

[wiebe@CARYA]

---

@altenbach wrote:

Look at all these local variables! (seen here)

---

All those frames aren't very pretty either.

Just to save people a click on the original post: it's a plain sub VI. If it where a GUI, the locals would make some sense...

[wiebe@CARYA]

I had a project where this was copied all over the place:

Now if you don't know how to do that the easy way, at least make a subVI!

Spoiler

[BowenM]

I recently volunteered to do some code review for the local university's physics program.  The first sample I was given was a goldmine, but this is my favorite so far:

Best part is the bd objects are in different locations in each frame of the SSS so it was clear they didn't even hit "Duplicate Frame" each time.  They recreated from scratch the same code 20 times.

(Disclaimer:  this was most likely written by a grad student who had never seen LV before and was just told to make it work)

[altenbach]

---

@BowenM wrote:

... and was just told to make it work) 

---

And I guess it actually "worked" 😄