Don't Allow Hidden Wires

[Amir_Y]

How many of you saw something like that:

I don't see any advantage for this to be allowed.

Wires can be treated as all other objects, not allowing resizing the structure when Auto Grow is ON.

This will force the user to cleanup the wire before resizing the structure.

(If I was brave enough I would suggest the Auto Grow OFF option should be canceled altogether).

Amir.

[Mads]

"Wires can be treated as all other objects, not allowing resizing the structure when Auto Grow is ON."

If this was the idea, I would consider voting for it.

However, I still want LabVIEW to allow hidden wires (yes, it should generally be avoided, but in some cases it gives a much cleaner code than the alternatives so removing it as an option would be bad), and I still want auto-grow to be ON by default (in fact turning it OFF goes against your other ideas because that makes you more prone to hiding code). So no kudos from me.

[Amir_Y]

Hi,

These ideas came from long experience of reading other developers code. There are many developers who write messy code using Auto Grow OFF and hidden wires. It took me many many hours to cleanup their code in order to understand it.

This experience made me appreciate clean code (and hate messy code).

Using Auto Grow OFF and hidden wires is messy code.

Can you give me any example where these option made any good?

Amir.

[Mads]

Ah, I see you have a double negative in the last sentence. I misread the sentence.

So, in fact we agree on two things; autogrow should by default be ON, and it should take wires into consideration.

However, the name of the idea suggests that you want it to be impossible to pass wires underneath other structures or nodes. In cases where a straight line is only possible if parts of it is underneath something else the clarity of having a straight line can sometimes (not most often, but sometimes) be higher than the alternative, To explicitly forbid this would not be ideal, as far as I see it.

[SteveChandler]

I actually like to be able to hide wires. I know that VI Analyzer complains and a lot of people don't like it. The diagram below shows about the only reason I like to hide wires. In this case I think it looks cleaner than having the queue reference go up and around the loop, or worse, through it, or even worse through the case structure.

[SteenSchmidt]

I hate autogrow, so would hate it being on without the ability to be turned off. I hate it because it mangles the surrounding BD when autogrowing. I can much better manage good coding style without autogrow. Regarding wires behind objects; Steve, I'd fail the programmer if I reviewed his or her code and it contained wires behind structures like that. I find it very confusing and a source of misunderstanding. The only time I'd allow wires behind objects is behind free labels, where the labels label the wire. Cheers, Steen

[Darin.K]

I can not figure out what this particular idea is or is not. I agree that the example shown has no business in LV. I am not convinced that Auto-'grow' is the problem or the answer. To me, the problem is you can shrink a structure beyond the bounds of it's content. I do not know when this is a good idea. Allowing overlapping objects is a different discussion, bad form, but I see no reason for such a restriction. My suggestion would be to never allow a structure to shrink smaller than its content rect. Second, I would like an option or a behavior change which would only allow a structure to auto grow into empty space. The one thing that must be addressed if it hasn't already is Type Def explosion.

[SteveChandler]

Well Steen I would never submit an exam with wires like that

It is just a different style and is very clear once you get used to it. It is a tradeoff for less wire bends. I actually learned this from some code posted online. The first time I saw it I had to do a double take because it is so unconventional and was posted by someone I consider a very good programmer and have learned a lot from. But once you get used to it it actually makes sense. There is only one place the wire into the release queue could be coming from. If you look at it closely you will start to see three dimensional G. Now THERE is an idea!

But I can adapt my coding style to the intended audience such as a grader or a new programmer on the forums asking for help with a producer consumer design pattern.

The point is that there are people who do hide wires and not out of laziness either. It takes more work to route the wire behind the structure like my example. But after reading the idea some more I realize that I may not have understood it completely. I definately see no reason to ever have a wire going outside of then back into a structure without a tunnel and would consider giving kudos to an idea like that.

[Amir_Y]

Thank you all for your explanations.

I think you finally got my point:

Don't allow hidden wires within a structure (when Auto Grow is ON).

Sorry if I wasn't clear enough in my first post.

Amir.

[SteveChandler]

Would the run arrow be broken if wires are hidden? If so then what about existing code? The problem with these things is that a lot of LabVIEW code is no longer written by humans but by LabVIEW itself through scripting.

I see that I wrote something pretty stupid above. "I definitely see no reason to ever have a wire going outside of then back into a structure without a tunnel "  You can only do that with a feedback node which means it is no longer the same wire. What I meant to say was "outside of or into a structure without a tunnel" or rather "extend outside the boundary of the structure"

I think a lot of people only look at the title of an idea before deciding to vote or not vote. They may decide not to vote based on the title alone. If it sounds like something they would support they will read on then decide. What I am saying is that if your idea is not simply "Do not allow hidden wires" you might want to resubmit it. I don't think I would vote for it. I think that if code is syntactically correct it should compile and run. If it is not readable by us humans that is our problem. The only solution is to teach people better programming style and if they are unable or unwilling to learn then they should consider a different career. If you mean just make it not possible with the editor to create wires outside the structure border then that might be ok.

[SteenSchmidt]

I kudo the idea that wires should behave like other objects with regards to autogrow. That must be the original suggestion, right?

Cheers,

Steen