LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Using shift registers verses global

Solved!
Go to solution

I am new to 2009.  Our last upgrade was 7.1.  I'm upgrading our lab SW and utilizing events.  EVENT 1:Is used to display data from a text file in a table "Data Set".  EVENT 2: Using radio button and the table "Data Set", the user selects the column of data to be used for the test which is displayed in a table "Test Points".  EVENT 3: If the user changes the data in the "Data Set" table, the "Test Points" test point table is updated.  I'm using local variables for "Data Set", "Test Points" and I was going to use it for other parameters as well (radio button, etc).  I was also thinking of using a shift register to carry that same information through.  I've used shift registers in the past and they can get messy but I also understand that you should stay away from variables.  Please pass along any advise on using local variables verse shift registers.  THANKS in advance!

0 Kudos
Message 1 of 5
(2,702 Views)

There are few, if any, absolutes in software design. One absolute that exists is that people will always jump on bandwagons. Of course, that's not limited to software design, since it applies to everything. The "local variables are evil" is one such bandwagon. What you should be staying away from are race conditions, not local variables. Local variables, if not used properly, can easily lead you to race conditions, but they are by no means a guarantee of creating one since you simply used a local variable.

 

Your general question is a bit vague, so I can say that without seeing some more detail I don't really see a need to have to use local variables for what you're doing. Could you use them? Sure. Is there a better way? Define better. The debate about local variables has been discussed to what seems to some of us as ad nauseam on this forum, so a search will yield a number of these posts and reasons why local variables are "bad". There is little point in rehashing them in yet another thread.

 

As for shift register "getting messy", well, any code can get messy. It sounds like you may be trying to use a different shift register for each parameter. This can lead to tons of wires which looks messy. One thing that I do it to create a cluster to store my "execution information" for the program. That way I have just one shift register, and I bundle/unbundle what I need within the individual cases. Much cleaner. Perhaps you could do something like this so you can have just one shift registers and you wouldn't need all the local variables.

0 Kudos
Message 2 of 5
(2,681 Views)
Solution
Accepted by topic author momof4

I am not sure what you defined as "EVENT 1" to "3", but they seem more like cases.

 

Using shift registers may appear messy, but they are way better than Local Variables if you have parallel threads going on in your code.

One way to clean up the wires between shift registers is to use clusters.

 

Locals do appear cleaner, until they "byte" you in the ....code...

 

EDIT:  "they are way better than Local Variables if you have parallel threads going on in your code"  I should explain... If you have parallel code which uses Locals Variables because this may lead to race condition(s)..

0 Kudos
Message 3 of 5
(2,680 Views)

THANKS!

0 Kudos
Message 4 of 5
(2,673 Views)

I agree with Saverio's post.

 

Locals do have their place but probably not for what you are doing.

 

Using a shift register containing a cluster of the important parameters and data also make very readable code, especially if you name the cluster elements logically and use (un)bundle by name.

 

Of course as anything in life, don't overdo it. For example don't do clusters within clusters within clusters ... with the innermost element being an array that constantly changes size. Make sure things are "in place" as much as possible, especially for more complex data structures.

0 Kudos
Message 5 of 5
(2,661 Views)