LabVIEW
Is it ok to use local variables for connector variables?
@Ben wrote:
@iCat wrote:
@P Anand wrote:
Yes but still its straight forward to connect the wire. Any specific reason for using the local variable?
It's cleaner with less wires.
If you hve any hope of ever getting certified as a LV developer, get out of the habit of using locals. You will loose point on your exam for using them when not absolutely required and "It's cleaner with less wires." will help.
Learn to write LV code without locals and your life will be easier.
OR ...
Ignore us keep using them and start a journal of your experiences so you can someday come back and tell US why we should not use locals.
So take our advise now and save yourself headaches or ignore us and learn for yourself.
I'll even give you a hint!
When you code start acting wonky, examine the local variables first.
Giving you enough rope to hang yourself,
Ben
Since you're so emotional about locals, there must be some gotchas other than just race conditions.
I changed all locals with wires directly coming from the actual control.
But I want to discuss one thing.
If I receive an input from a control in a connector and only read from it via locals, since all locals only read from it, I guess there would be no race condition as illustrated in my last article.
Am I wrong?
@iCat wrote:
Since you're so emotional about locals, there must be some gotchas other than just race conditions.
Isn't that enough? The truth is that locals don't cause race conditions. Programmers cause race conditions. And programmers abuse and misuse local variables to a far greater frequency than anything else. This is mostly from text-based programmers. That's why they're not recommended./
If I receive an input from a control in a connector and only read from it via locals, since all locals only read from it, I guess there would be no race condition as illustrated in my last article.
Actually, there is a race condition. You're just not seeing it. And that's the problem. You've just proven our point without realizing it. 
The control value can change independently of when the local variable is read. Hence, the local variable can be read first, and then the control value is changed by the user. Ergo, race condition.
@iCat wrote:
...
Since you're so emotional about locals, there must be some gotchas other than just race conditions.
I changed all locals with wires directly coming from the actual control.
But I want to discuss one thing.
If I receive an input from a control in a connector and only read from it via locals, since all locals only read from it, I guess there would be no race condition as illustrated in my last article.
Am I wrong?
That piece of code... yes you will get away with that one but let me try to illustrate why many of avoid use as you have shown. I repeat you image below.
Let's say your rookie you are training is supposed to make a "small change" (hack hack, cough cough) where the user wants to be able to change the value of "range collumn" so your rookie puts a while loop with an "OK" button around the CONTROL INSIDE the nested case and set the VI to "Show FP if Called" etc.
When your rookie test out the code, they will find that the code is not using the value specified by the user, but rather what the value was when the VI was called. I'd call that wonky.
The reason you would get that result is (watch the code in execution highlighting, light bulb on) that LV will more often than not process all block diagram functions that do NOT have any data dependencies. In the code above the "Read of the local" is one of the first thing executed. Any changes made by the user will be ignored.
So yes the code as it stands, if used as plain sub-VI will get away with that code construct.
But the contributors to this forum do not teach people "how to get away" with witing LV code but rather how to wire right in the first place. Part of wiring right is to develop code that is easy to understand, maintain and enhance. As the scenario I outlined above shows, there is a "gotcha" waiting to bite due to using a local.
But as I just stated we try to help people learn how to do it right and encourage good programming habits. There is yet another monster hiding under the cloak of the local that is not illustrated in the above code and that being "performance". If you use those habits and methods for a control that has a large data set you eventually suffer performance issues that result from buffer copies. (You can view buffer allocation using the tools >>> Profile >>> Show buffer allocations).
With normal strings (normal i.e. standard words less than ... 25 characters or whatever) you will hardly see the hit. But if the control/local help a big block of info, the application would have to duplicate the buffer for each local copy on your diagram. The copies take CPU to move the data, Memory to hold the copy, and Kernal mode time to allocate the memory.
Memory that would not have to be copied if we just used a wire.
So again, the earlier you stop using locals and stat thinking that your "data is in the wire", the sooner you will be developing a$s-kicking code.
have fun!
Ben
G-Wiz comics can be found here.
