12-04-2014 03:00 AM
@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
12-04-2014 04:01 AM
@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
12-04-2014 10:08 AM
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.
12-04-2014 12:06 PM - edited 12-04-2014 12:18 PM
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.
12-04-2014 01:05 PM
@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!
12-04-2014 02:09 PM
@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. 🙂
12-04-2014 06:01 PM
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.
But it doesn't help any more. Is this a side effect ?
Can we get the feature back ?
12-04-2014 08:43 PM - edited 12-04-2014 08:45 PM
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.
12-05-2014 12:51 PM - edited 12-05-2014 12:55 PM
@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.
12-05-2014 01:55 PM
I have a habit of double and triple clicking wires in order to follow them. I usually find these kinds of errors with that.