Quote:
Originally Posted by XXShadowXX
1) Local variables (and global to an extent) are made of pure evil. They seem fast and fun when writing code, but they aren't. Each write and read clones the value in memory (at least in Windows/Linux/OSX), I don't know about cRIO but its just a 'best practice thing''. They're bad, don't use them. They make debugging your code harder, and cause extra memory usage (also sometimes labview just doesn't track where locals and global are being read/write, so you may have a errant write in an unexpected location).
|
Be careful when giving this advice. I agree, with one exception. When you are coding in the WPILib framework, you
need to use global variables and
can't be afraid of them. The reason for this is that if you are coding the right way, you will be doing a lot of communicating between Teleop.vi and Periodic Tasks.vi. By far the most practical way of doing this communication is via globals. There are also other good uses for globals, such as using one to create a sort of fake enum for all of your refnum names.
Also, 20 minutes is not a lot of time to teach a bunch of beginners about LabVIEW, and things get even more complicated when you have some experience in the mix that you don't want to bore. My recommendation would be to not even bother trying to touch upon how to actually code, instead just link them to guide that will teach them how like
this one. Your time would be better spent talking about the LabVIEW environment and WPILib framework. Talk about some good overarching principles like data flow and documentation and good debugging practices. Make sure they know how important it is to establish a good way to share code, giving SVN, GitHub, and email/flashdrives as examples. And most importantly, make sure they know where to look for help when they need it (Chief Delphi would probably be a good place).