Leaderboard

http://forums.openg.org/index.php?showtopic=820 http://wiki.openg.org/Arithmetic_Mean_(Functional_Spec) From the old fora's I believe there wasn't made any decision yet... was there?

If this wasn't long enough then I wanted to add that I pass the class between parallel loops as a DVR which is controlled as a singleton through ESF. Thus, each section of the logic that needs access to the db will ask for permission and lock the db till it is finished doing what it wanted to do. LV is great with classes inside a DVR, you can use properties on it just as if it was a regular class.

In general, Darren and I add comments to our diagrams when, during a buddy session, we actually have to explain what's going on to the other. That's our standard measure for when a comment is needed. If the buddy session proceeds without the other person getting lost as we walk through, then the code and the API documentation (i.e. the Context Help) likely suffices as it is. My instinct in this case would be to put a Diagram Disable structure down and put the other version that I had tried in the Disabled frame -- then I don't have to describe what I tried, people can look at it. Now, that is only true when the other version of the code is all prims or vi.lib VIs, things that don't cause my source code to have additional dependencies when distributing it. As much as possible, I would still prefer to include the graphical "here's what I tried" and avoid a text description of it. It is both more accurate to say "I tried this" and if someone else says, "But that other way really should, by rights, be faster..." they can benchmark it themselves easily and/or spot any errors I had in my implementation. And if the compiler takes advances, it's easy to flip in the other code.Now, having said all of that, I do tend to include "proof of correctness" comments with complex algorithms, along the lines of "This loop works because earlier in this VI we already guaranteed that there are no duplicates in the array". This is especially true when I'm relying on a less-than-obvious fact of one of the upstream functions. For example, I recently wrote a VI with the comment "This works because the Controls[ ] property of a Front Panel refnum guarantees that the controls are returned in tab order." Most people analyzing my code for correctness wouldn't know that fact, even if it was properly documented (it will be in LV 2012), so it was worthy, IMHO, of a comment.