LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Wire "Hidden" behind structure in LabVIEW 2014


@zou wrote:
[..]

If it's opaque, add this to your .ini file:

structuresFadeToDiagramBeneath=TRUE

 


Why would i add a key to my LabVIEW.ini to display things which are clearly breaking fundamental Best Practises For Code Design?

To recall that best practise (aka Style Guide): Never hide wires behind structures.

 

Norbert

Norbert
----------------------------------------------------------------------------------------------------
CEO: What exactly is stopping us from doing this?
Expert: Geometry
Marketing Manager: Just ignore it.
0 Kudos
Message 11 of 24
(1,665 Views)

@Norbert_B wrote:

@zou wrote:
[..]

If it's opaque, add this to your .ini file:

structuresFadeToDiagramBeneath=TRUE

 


Why would i add a key to my LabVIEW.ini to display things which are clearly breaking fundamental Best Practises For Code Design?

To recall that best practise (aka Style Guide): Never hide wires behind structures.

 

Norbert


Often enough if you inherit bad code or move e.g. a case structure you can end up with wires behind structures. To see them somehow is a good help to know you need to clean stuff up.

/Y

G# - Award winning reference based OOP for LV, for free! - Qestit VIPM GitHub

Qestit Systems
Certified-LabVIEW-Developer
Message 12 of 24
(1,657 Views)

natasftw wrote:

Why would you be trying to hide wires behind strucures in the first place?

 

 

OCD?  Haha.

 

The same reason NI created this .ini entry, I guess.

 

George Zou
Message 13 of 24
(1,620 Views)

In all fairness, I know many very competent developers that will sometimes run wires behind structures. There are certain cases where I don't think it obfuscates things too much, and I'd rather have the straight wire. NI best practices are a guideline, but certainly not strict requirements. Also, I wouldn't get too high and mighty on a set of style guidelines that the generator of said guidelines often doesn't follow themselves. Ask 10 developers their opinion of certain styles and you will get 10 different answers. I don't disagree this particular one may be bad practice, but I also wouldn't just assume NIs style guide is the golden standard. 

 

That said, Yamada brings up a good point as well.

 

"The same reason NI created this .ini entry, I guess."

 

This made me laugh.

Message 14 of 24
(1,599 Views)

@Yamaeda wrote:

@Norbert_B wrote:

@zou wrote:
[..]

If it's opaque, add this to your .ini file:

structuresFadeToDiagramBeneath=TRUE

 


Why would i add a key to my LabVIEW.ini to display things which are clearly breaking fundamental Best Practises For Code Design?

To recall that best practise (aka Style Guide): Never hide wires behind structures.

 

Norbert


Often enough if you inherit bad code or move e.g. a case structure you can end up with wires behind structures. To see them somehow is a good help to know you need to clean stuff up.

/Y


That is why you run VIA on inherited code!  No super-secret ini key needed!


"Should be" isn't "Is" -Jay
Message 15 of 24
(1,576 Views)

@zou wrote:
The same reason NI created this .ini entry, I guess.

NI created the config token in order to test out an idea for helping you find *and fix* code behind structures, not so you can code more behind structures. 🙂

Message 16 of 24
(1,550 Views)

When we upgrade / add new features for a customer, we are NOT paid for improve the diagram.

It would be best that we can live with it, and focus on the new features.

 

 

 

 

 

George Zou
0 Kudos
Message 17 of 24
(1,508 Views)

George why would you want the feature back when you have VI analyzer?

 

that ini entry was a failed experiment that showed the power of vi analyzer.

 

Use VI analyzer.


"Should be" isn't "Is" -Jay
0 Kudos
Message 18 of 24
(1,493 Views)

@JÞB wrote:

George why would you want the feature back when you have VI analyzer?

 

that ini entry was a failed experiment that showed the power of vi analyzer.

 

Use VI analyzer.


Because when you are debugging, a lot of times you don't even know a wire is behind a structure in the first place. I don't want to run the VI analyzer every single time I inherit an application just to see if some developer may have followed bad practices, then go sift through all the failures (of which there could be hundreds, or more) and figure out which may cause bugs at some later point in time.

 

George is referencing the specific case where he is looking at a VI, it is not working as expected, and if he could see that a wire was run behind a structure the fix would be quick. The VI analyzer in my opinion is not the best solution for this problem. Ever had a tunnel you thought went through a structure and didn't? My first thought isn't "maybe I need to run the VI analyzer to fix this bug." The VI Analyzer to me is a very powerful code review and style-enforcing tool, but I have never opened it specifically for debugging.

Message 19 of 24
(1,445 Views)

I have a habit of double and triple clicking wires in order to follow them.  I usually find these kinds of errors with that.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
Message 20 of 24
(1,425 Views)