Seems to me 75% of the time when I create a local variable, I need to read it, not write to it.
For me, I would say it's the other way around.
Most of the time, I write to indicators to display a value to the user, and to controls to preset a value before actual user input.
I never read the value of an indicator, because if I needed the written value for something else, I would have stored it already in a shift register of my state machine.
When I need the value of a control entered by the user, I usually have a corresponding "Value Change" event case from where I can read it (old and new values from the event data node).
The only case where I need to actually read from a control (using a local read) is when an action requires user inputted parameters for which I don't want to implement a "Value Change" event case. I try to minimize this case in general.
If you are not in these use cases, it may mean that you are either:
- using locals as a data storage mechanism;
- using locals for sharing data across multiple parallel loops instead of using queues / notifiers / user events / RT FIFOs...
These 2 examples are usually considered bad practice as they can lead to race conditions.
Also, using locals in non-GUI VIs will force the compiler to include their front panel in your built application, which will take (a little bit) more space
Changing the read/write default of local variables has been discussed in Idea Exchange before, and there hasn't been a lot of support for changing it.