I’ve made a Software Development Guide geared towards FIRST teams using LabVIEW.
http://kamocat.com/programming/FRC_style_guide.pdf
I’m looking for feedback and suggestions for improvement.
There are plenty of good elements there, but several of those don’t really apply to LV Realtime and/or are dated to older versions of LV.
In particular, the comment about slowing down while loops or using event structures is good advice for UI loops, not for robot loops. The correct approach there is to use the loop time appropriate for the sensor or actuator. You will probably not be doing UI loops.
The comment about building an array in a loop is somewhat dated. LV has implemented more and more heuristic optimizations over the years, and while the more complex code is going to be somewhat more efficient, it is often much harder to read and write, and the difference is often quite small. I’m not saying that this isn’t a good tip when you are trying to optimize performance for a particular piece of code, but it is not a good tip for general code usage – at least not IMO.
The global and local variable comment is a big one to watch, specifically, keep the writers to a minimum, and especially watch the read/modify/write sequences to them. Build a functional global instead – google it.
Since you are not generally dealing with arrays at all in robotics, I wouldn’t worry too much about coercion dots. In fact dots between signed and unsigned ints do not even cause any additional storage or code. There are plenty of other cases where a primitive can implement a coercion dot with no work or code. While there will occasionally be an expensive conversion, simply getting rid of the coercion dot by putting in an explicit conversion bullet will not actually fix the problems, simply take more code to do the same work. Other means for getting rid of coercion are far more effective.
Indicators automatically compare data and optimize this case for you. You don’t really need to compare to avoid updating an indicator. On the other hand, on RT, it is very useful to do this for UI property writes, and to avoid reading them any more often than needed.
Mostly what I’m saying is that this list is a starting point that I mostly agree with, but be sure to question the items and see if you can thin it out over time or more directly pinpoint when it is important to write extra code or spend extra time.
Greg McKaskle
I’ve done another revision.
Corrected typos and made small clarifications.
Added introduction for clarification of the process and intent.
Revised and recategorized style guide.
http://kamocat.com/programming/soft_dev_FRC.pdf
I welcome any feedback or suggestions.