LabVIEW Idea Exchange

About LabVIEW Idea Exchange

Have a LabVIEW Idea?

  1. Browse by label or search in the LabVIEW Idea Exchange to see if your idea has previously been submitted. If your idea exists be sure to vote for the idea by giving it kudos to indicate your approval!
  2. If your idea has not been submitted click Post New Idea to submit a product idea to the LabVIEW Idea Exchange. Be sure to submit a separate post for each idea.
  3. Watch as the community gives your idea kudos and adds their input.
  4. As NI R&D considers the idea, they will change the idea status.
  5. Give kudos to other ideas that you would like to see in a future version of LabVIEW!
Top Authors
Showing results for 
Search instead for 
Did you mean: 

improve VIAnalyzer locals detection rule

Status: Declined

Any idea that has received less than 4 kudos within 4 years after posting will be automatically declined.

Right now, LabVIEW VIAnalyzer detection rules for Locals and Globals is very simple -- count the number that exist and flag if number >= constant. 


However, I'd find it more useful if I could filter out certain usages of locals/globals and not count them in the total count of locals/globals.


The usage that I would like to filter out is when the local/global is used "as a type" rather than for the value (granted the example below has the "MyCustomControl" being used as a type really also is being used as value for any items not specifically assigned in the bundle by name, but let's ignore that for now).


I would imagine VIanalyzer configuration for the globals/locals rule would change to look something like this:



which would NOT count locals that are used in situations like this:



(Sorry, VIsnippet didn't work out right for locals)


Trusted Enthusiast
Trusted Enthusiast

Replace them by constants!

Active Participant

I have in some cases.  But in others, I create multiple versions of similar VI's (think replicating for a polymorphic instance that supports i32, i16, i8, u32,u8,u26,string,boolean,double.....) and in those cases the extra work to go change all the inputs, outputs AND constants to the new type is more work than just the inputs and ouptus.

Knight of NI

That is what you would use a typdef for.

Active Participant

Changing to a typedef doesn't solve the problem of having to replace more items, and wrapping a single i32 into a typedef doesn't help -- it just adds a bunch of overhead.


I don't see any problems with using locals in the way I have.  I will agree that there are other ways to do it that could also work (there's always more than one way to do things), but (with the exception of bundle by name if not all items are specified) none of the other examples breaks dataflow, which is the primary issue with locals.  And sometimes speed of execution does not matter.  Using the locals for types adds some benefit aroud self documenting the code becuase I now know that I am trying to convert to that type because I want it to match output value for "myIndicatorName" (instead of converting to a i32, and then needing to document why an i32 is important, and how "myI32output" is also an I32 and that's why I chose an I32 ---- and then when I choose to change my code to and i64, my documentation is incorrect and my typeconversion is incorrect and the chance that I will remember to fix both of those under timecrunch pressure is low). Wrapping that I32 into a type could work, but that's a lot of overhead, and then using that value for other things (like add function) has lots of coercion dots at a minimum.


Just like any other coding structure, there are appropriate ways to use locals, and there are wrong ways to use locals.  The examples I showed only breaks the "best practices" rules about locals if the bundle by name does not assign all values.  Therefore, why not add an option to VIanalyzer to ignore uses of Locals that are only used for their type and not value? (Note -- I'd love to see a rule to check "I have a dataflow violation and likely race condition with this global/local" but I can't think of a way to reliably implement that one)  If you still want to have VIanalyzer flag EVERY local in your code, you make sure the box is (checked/unchecked).  Otherwise you can (uncheeck/check) the box and have a cleaner VIanalyzer report.  Within VIAnalyzer, we need to work to get it to the level where we can detect items that are likely causing problems (like locals that violate dataflow and would run into race condition issues) and differentiate them from items that are coding style (which is somewhat cosmetic and is different from company to company and person to person and even project to project).  Then I can configure my VIAnalyzer rules to choose the level of code issues vs style issues that **I** want to find, and be able to concentrate my job of fixing/cleaning up the code to *My* requirements, and not spend extra time filtering through 'false hits' in the VIanalyzer list or deoptimizing code for the sake of making my VIanalzyer result list smaller so I can get signoff from my project leader, or have an easier time sorting through the list next time I run the tool.


Proven Zealot

I can sympathise with warren on this one.  Until we get proper polymorphism or generic datatypes, I find myself doing this more often than I would like.


It works and saves time.  Of course the data copy at the local read can bite you in the rear if you're not careful but otherwise I don't see the problem with it.  If the compiler would actually compile this out into the respective constant, that would be groovy.

Active Participant

I am not sure if VI Analyzer does anything inside of Diagram Disabled Structure, but if doesn't this may do the trick? This also avoids the data copy.



Certified LabVIEW Architect 2013
Proven Zealot
Status changed to: Declined

Any idea that has received less than 4 kudos within 4 years after posting will be automatically declined.

DNatt, NI