Visual indication that a structure is hiding code beyond its boundary

[fabric]

Preamble:

Just following up on a sub-idea raised within this recent idea from tst: LabVIEW should break VIs which have hidden code.  I *almost* like tst's idea, but IMO it is a bit too heavy-handed:

• YES, I want better information when there is hidden code on my diagram, but...
• NO, I don't want my code to break!

The Idea:

If a structure hides code beyound it's boundary, then provide a visual indication. For example, the edge of the structure could be coloured red to alert the user that something unexpected is going on.

 

[SteenSchmidt]

@fabric: You have a point (or several). In that case it would be better coloring the border(s) that needs yanking in to reveal the hidden code. Nevermind messing up the top edge; The hidden code must be unearthed or the structure stay messy!

Looking at an image like this makes me wonder why it's not already in LabVIEW?:

/Steen

[SteenSchmidt]

Just my 2 cents on code breaking/not breaking;

I definetely do not want my code to break just because it's hidden. Bad bad style, yes, but not broken.

Breaking code based on hidden graphics would to some extent compare to a C-compiler refusing to compile a source file if you didn't wordwrap long lines that stretch outside the display border. The LabVIEW IDE is an editor. It should provide us with visual cues that we are making a mess at editing, but it shouldn't break our code based on this. If it did so we would definetely have an impossible task explaining the difference between MS Paint and the LabVIEW IDE. That would be too tight a bound for my taste ("Oh, I found out why your compilation took so long; you've colored this subdiagram RED. Silly you!").

/Steen

[tst]

---

...but it shouldn't break our code based on this. If it did so we would definetely have an impossible task explaining the difference between MS Paint and the LabVIEW IDE. That would be too tight a bound for my taste ("Oh, I found out why your compilation took so long; you've colored this subdiagram RED. Silly you!").

---

I think that's neither fair nor correct. My suggestion is about compilation, but you know that in LV that's effectively an edit-time behavior. There are enough real issues with it without making up new ones.

[SteenSchmidt]

@tst: I'm not sure what wasn't fair nor correct in my prior statement, but I definetely made up a new (non-existing) issue. That was merely an attempt at a joke

Anyways, I'll elaborate and hopefully accidentally explain the issue that you find unfair;

- Compilation, while happening at edit-time (except for FPGA where compilation is definetely an offline activity), can still be a lengthy process. Slow compilation translates into an unresponsive or sluggish IDE, so it's still an issue even if it happens at edit time. I'm not saying it is an issue now, I'm not even saying it will be in the future. I was just using it to underline my next point:

- My point with 'compilation' and 'a red subdiagram' was to underline some apparent silliness in linking a visual aspect with LabVIEW's willingness to compile my code. In my view these should be unrelated. Very fine with me if this graphical IDE gives me a visual cue that something is non-optimal in my edit, and god speed also to tools that help me find such stuff easily, but I wouldn't like that visual aspect influencing the binary code, nor interfere with my ability to generate that binary code. Another analogy would be if a data assignment took longer because the wire was longer. It doesn't make sense for me. And it would maybe even stop some scripted code from working*.

- My remark about MS Paint and LabVIEW stems from very real experiences. Non-LabVIEW software developers sometimes stop by my desk, glance at my display, and spawns of remarks along the lines of just that. For instance "You're really drawing software?". Or "That isn't real code, right?". Or when some bug needs to be hunted down: "You should probably try with Photoshop instead of MS Paint... giggle.". And then I have to defend LabVIEW and tell these people that this is actually a high-level programming language with events and everything, but often I just end up telling them that I'm a certified software architect, they're not. Come back when that changes! So, I'm not keen on features that makes the balance tip further toward how I draw something influencing the compiler. I can just hear the next remark if I had a broken arrow due to some code being hidden, and some non-LabVIEW programmer watched me unearth that; "Ah, your code was hidden! Of course the compiler couldn't see it then. Good for you you found it, so now we can proceed?". No, not gonna happen if I can have a say .

As always I'm 100% for defending everyone's right to their own oppinion, also when it contradicts my own. The above was in no way meant to put a spoke in your wheel, I was just making a bad joke. Sorry about that.

Cheers,

Steen

* The case here is when you script a VI just to fire and forget, sometimes this (temporary) VI will look real messy on the BD since you didn't take into consideration where the objects are placed, just how they are wired. It'll be a much taller order if some BD style has to be enforced for the code to be able to execute as well.

[tst]

Ideally, you would be right, and warnings would be enough for this, but unfortunately, warnings don't work for this. The compilation error is not meant for LV's benefit, but for ours. We already covered all this in the other thread, but I will post this, since I haven't before:

LV would break code which uses either of these samples, even though it could meaningfully compile it. The only reason LV breaks these is because NI decided that for the vast majority of the time (probably at least 99.9999%), people would not want the code which results from this, and if they did, they could do it manually. But NI breaks it as an aid for the developers, not because LV can't deal with it. You don't seem to complain in that case (although Darin does).

And yes, I think that anyone developing in another language would be justified in making fun of LV because it hides code, and probably also because the tools which protect you from it can only do so by breaking the code, but until the physics based layout gets here, I haven't seen a better way of solving it yet.

[SteenSchmidt]

I'm not surprised either of your examples won't compile, what do you suggest a meaningful compilation would be in each case?

/Steen

[tst]

> what do you suggest a meaningful compilation would be in each case?

The multiply prim would output 0 (because the bottom input is 0) and the loop would run zero times and output an empty array. The only reason this doesn't happen is because NI decided to make LV usable, not because the compiler needs this. You can find quite a few examples like that in LV. My point was that deciding what's compilable is made not only based on what the compiler can do, but also based on what would benefit the programmer.

[SteenSchmidt]

Ok, but that is due to required vs. optional inputs. You don't find a binary (two-input) multiplication function in any programming language with optional inputs. Those will always take two inputs. Also, no input on a For-loop usually translates into an infinite loop (for( ; ; ) in C for instance).

But agreed, we're talking about definition here. The usual definitions tend to not break compilability due to currently invisible source code. Imagine a text-based programming language that had a requirement that all files had to be open and all text visible for compilation to proceed. That translates into all code in every Top-Level and subVI being visible at the same time, to get rid of the broken arrows.

Definitions can be changed of course, but I don't see how hidden code in a structure is different from code hidden in another frame of a case structure, beyond the screen border on the BD, within a subVI etc.?

/Steen

[tst]

> Imagine a text-based programming language that had a requirement that all files had to be open and all text visible for compilation to proceed

That would be completely ridiculous, and it's not what I'm suggesting. Like I said in the other thread, the parallel which should be drawn would be more similar to VS allowing you to accidentally change *some* of the source code to white on white (you can apparently already do this as a global setting), which I think you'll agree is not desirable.

And, like we also discussed in other threads, this isn't just about code hidden in structures. I think it should apply to any code which is overlayed by something else. The difference between such code and any other example you will bring up is that the other examples are intentional and have a clear indication in the diagram, whereas this is usually unintentional (although as you and Daklu pointed out in the other thread, there are cases where people do use this explicitly) and completely invisible. You could add a visual indication so that it isn't invisible (and I'm pretty sure someone already suggested that 😉 ), but my problem with that is exactly that there are numerous ways to hide code, which would require different indications for the hidden code.

[SteenSchmidt]

I'm not disputing it's a problem (usually) when code is hidden, I'm just objecting to it being a matter for the compiler. I'd much rather see it handled better; by letting the IDE do a better job of indicating when it happens, or alternatively enhancing the IDE to eliminate the (albeit rare) need for hidden code. In my mind that is where the fight should be fought.

Better indication of hidden code is taken care of by ideas such as this particular one. This aims at structures. Then comes all the other ways code can be hidden, mainly objects on top of other objects. We need good ideas to indicate that.

Eliminating the need for hidden code will probably be a bit further out in the future, since I think the solution(s) to this lie somewhere in the auto-arranging BD (physics based or something else) and the decoupling of code from design. The first step toward the latter will be decoupling of the BD from the FP, hence redefinition of the VI itself. Not all these steps may be necessary, but any of them are a high number of LabVIEW versions out. First steps towards solving this part will be to identify where exactly do we run into justified hidden code?

/Steen