A Thing of Nightmares. Recommendations when reworking abhorrent code?

[etvg]

For your amusement I found this response to someone asking for the password, located in this thread: https://forums.ni.com/t5/Dynamic-Signal-Acquisition/Lock-in-Amplifier-and-DAQmx/td-p/282419

"National Instruments does not provide the password for the block diagram for this VI because it contains National Instruments proprietary information. You shouldn't need the password to use these VI's." 

Proprietary wiring methodology I presume 

[wiebe@CARYA]

Excited to see how much crapcreative code NXG's zoom in\out will bring us. I think we're lucky it wasn't available 20 years ago, when there where no coding standards\morals at all.

[etvg]

Yeah, I could only imagine what this code could have become with such an ability. 

[RTSLVU]

---

wiebe@CARYA wrote:

Excited to see how much crapcreative code NXG's zoom in\out will bring us. 

---

OMG I didn't know that was part of NXG...

I fear the worst, because being able to zoom in and out will make it really easy to create OBL (One Big Loop)  programs instead of using a proper programming architecture. 

People will make huge block diagrams and say "well you just move here and zoom in to work on this part and zoom in over there for that part".

[etvg]

The Prezi presentation of coding, one might say.

[wiebe@CARYA]

Yep. I do see a need for a zoom in, as you don't want a 1 pixel wire on a 32k screen that we might see in 10 years. But zoom out is a terrible idea.

[JÞB · Accepted solution]

---

@etvg wrote:

It does work. However while I am running experiments in the lab I usually sit down with the code and try to make it simpler. The whole code used to be written in this same manner as some of you have seen in previous questions (@altenbach @bob_schor), and I would like to continue to make it user friendly for the next guy, as I leave in six weeks. I suppose it can be seen as a challenge as well. 

Cheers

---

Well now, That makes it easy!!!  Take a six week vacation and change your name.

[RTSLVU]

---

wiebe@CARYA wrote:

Yep. I do see a need for a zoom in, as you don't want a 1 pixel wire on a 32k screen that we might see in 10 years. But zoom out is a terrible idea.

---

But this is something that NI could really fix without the need for zooming.

1. Put an absolute limit on block diagram size (there really should be one anyway)
2. Make the block diagram automatically "fit to window" when maximised and the screen is larger than the maximum block diagram size.

[Ben]

---

@RTSLVU wrote:

---

wiebe@CARYA wrote:

Yep. I do see a need for a zoom in, as you don't want a 1 pixel wire on a 32k screen that we might see in 10 years. But zoom out is a terrible idea.

---

But this is something that NI could really fix without the need for zooming.

1. Put an absolute limit on block diagram size (there really should be one anyway)
2. Make the block diagram automatically "fit to window" when maximised and the screen is larger than the maximum block diagram size.

---

From the crashes I have seen with diagram clean-up and very bad code, I think there is at about 65535 pixels wide.

Ben

[altenbach]

---

wiebe@CARYA wrote:

Yep. I do see a need for a zoom in, as you don't want a 1 pixel wire on a 32k screen that we might see in 10 years. But zoom out is a terrible idea.

---

Getting a bit offtopic, but I always thought that a dynamic "zoom bubble" that follows the cursor would work great (see also this post). Such simple dynamic nonlinear re-scaling would be no problem for any modern graphics hardware. Now you can precisely position the mouse in the area of interest without losing track of the big picture. 😄