LabVIEW
Best practices on how to document code?
Solved!
@f. Schubert wrote:
Just a rough draft during the first coffee:
...
Ben, you are the advocate of the tree vi. I'm sure you have more to say on this.
Felix
You covered it pretty well. I mentioned Tree.vi's in my Nugget on using Type Defintions as shown in this preview.
We use a Tree.vi in almost every application we develop. Another synomyn is "Catalog.vi" becuase they act as a way to quickly find part of the aplication.
Although the project has helped with some things the Tree.vi used to do, it is extremely useful in applications that have dynamic components (as mentioned above). The tree is included as part of standard policies in that we have a rule that states "Never save a broken tree to the server." (We have a bad pun that goes with this situation. Our projects are servered via teh "O" drive. So when a rookie asks me if they should save the code to the server with the tre broken I reply "O NO". I did warn about the bad pun).
I think the only thing I can add that can illustrate how seriously, I one overheard my boss asking a developer that was having trouble, "Why aren't you developing with the tree open?".
Take care,
Ben
I first thought you with Tree VI meant folder structure. The documentational vi is an interesting idea.
The folder structure is also a way to document code, if VI's have similar names (and they will have when the projects gets to a few hundered vi's) the placement is helpful in quickly understanding what it's supposed to do. (Then i prefer to use quick help open so i can see the paths by mouse over)
Since the Documentation property is shown at the same time that's even more important ofc.
To many the folder structure is so natural you forget to mention it, but i thought it was worth mentioning. 🙂
/Y
