Rube Goldberg Code

[santo_13]

---

wiebe@CARYA wrote:

I keep wandering if there is a reason to put those constants outside the loop.

I don't think it's faster (anymore)? Is this just habit? Or preference?

I personally prefer the constants inside the loop... Not looking for a flame war, just curious.

---

My preference would be the latter and this reflects @altenbach's reasoning precisely. I just have the habit of reducing as much free space inside the for loop, if the i terminal is unused, I would move it to a corner or hide it (I guess this is a feature from LV2020).

[JÞB]

---

@santo_13 wrote:

---

wiebe@CARYA wrote:

I keep wandering if there is a reason to put those constants outside the loop.

I don't think it's faster (anymore)? Is this just habit? Or preference?

I personally prefer the constants inside the loop... Not looking for a flame war, just curious.

---

My preference would be the latter and this reflects @altenbach's reasoning precisely. I just have the habit of reducing as much free space inside the for loop, if the i terminal is unused, I would move it to a corner or hide it (I guess this is a feature from LV2020).

---

Since I usually set my ini file to the non-default "Show Created Constant Labels by Default" , I migrate the folded constants myself even though the compiler will "Rarely limit Optomizations" ( yes, I keep that option at a non-default 10 .)  It may make development time longer to document and migrate constants as written but I seldom have to be asked "What do they mean?"  It also makes them searchable.

[wiebe@CARYA]

---

@santo_13 wrote:

---

wiebe@CARYA wrote:

I keep wandering if there is a reason to put those constants outside the loop.

I don't think it's faster (anymore)? Is this just habit? Or preference?

I personally prefer the constants inside the loop... Not looking for a flame war, just curious.

---

My preference would be the latter and this reflects @altenbach's reasoning precisely. I just have the habit of reducing as much free space inside the for loop, if the i terminal is unused, I would move it to a corner or hide it (I guess this is a feature from LV2020).

---

I always try to minimize wire length and tunnels.

I usually like the constants as close as possible to where they're used.

Both strategies seem valid ways to achieve readable code.

I guess we all leave our 'signatures' in the code we make.

[VinnyAstro]

---

@santo_13 wrote:
[...] if the i terminal is unused, I would move it to a corner or hide it (I guess this is a feature from LV2020).

---

Yes it is, also for the while loops and it is very enjoyable (imho) the only issue I have is that I would have preferred they put the option in "visible items" instead of making longer and longer menus.

[altenbach]

Yes, I always thought that the "conditional terminal" and the "iteration terminal" visibility option should be under the "visible items" section of the right-click menu. Similarly, these options are also missing from the properties page, which is quite anemic for FOR and WHILE loops.

[wiebe@CARYA]

I always hide them if they're not used. The old "less is more" cliché 🙄.

It doesn't work well when shrinking though (CTRL+ALT+drag). The iteration terminal disallows shrinking. A workaround is to shrink the other way, so it's not a big problem.

[altenbach]

---

wiebe@CARYA wrote:
I usually like the constants as close as possible to where they're used.

Both strategies seem valid ways to achieve readable code.

---

Another example from here:

[wiebe@CARYA]

---

@altenbach wrote:

---

wiebe@CARYA wrote:
I usually like the constants as close as possible to where they're used.

Both strategies seem valid ways to achieve readable code.

---

Another example from here:

---

I don't think it's ugly inside the loop. It removes 2 wires and 2 tunnels and 4 terminals. Seems like an improvement to me.

If it where a control, it should of course be outside the loop for performance reasons.

[altenbach]

To turn two booleans (from two "is value changed" vim) into an integer apparently takes six diagram constant, two selects, two comparisons, and two case structures and lots of orange!

How can that possibly be simplified???

(seen here)

[Jacobson-ni]

---

@altenbach wrote:

To turn two booleans (from two "is value changed" vim) into an integer (0...3) apparently takes six diagram constant, two selects, two comparisons, and two case structures and lots of orange!

How can that possibly be simplified???

(seen here)

---

This one took me quite a while to figure out what was going on.