Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page
LV Style Guide
bfarley
Member
10-28-2004 03:28 PM
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report to a Moderator
I was asked the following:
If you were to hire someone to develop LV code which you will have to maintain, what requirements would you levy?
The attached is my first cut at an answer. Basically a coding guideline. It summarizes about all I can find on the issue along with some of my own preference. Comments encouraged.
Thanks,
Bill F
If you were to hire someone to develop LV code which you will have to maintain, what requirements would you levy?
The attached is my first cut at an answer. Basically a coding guideline. It summarizes about all I can find on the issue along with some of my own preference. Comments encouraged.
Thanks,
Bill F
TylerS
Member
10-29-2004 10:39 AM
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report to a Moderator
The coding standard pretty much covers everything that isn't specific to your situation (e.g. file naming conventions).
djs_at_eaton
Member
11-01-2004 07:51 AM
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report to a Moderator
LabVIEW code Checklist
From The Software Engineers Guide to LabVIEW by Conway & Watts. This is an excellent book. It's pricey, but worth every penny.
1) All code runs without reported errors.
2) Front panels are well laid out, and inputs and outputs clearly defined.
3) All user facing front panels and user interfaces are clear and obvious as to their function.
4) Each icon is meaningful.
5) Each VI name is meaningful.
6) Each component exhibits strong cohesion and is loosely coupled.
7) All interfaces to components are clearly defined.
8) Each VI has the description section filled in.
9) Each VI diagram is clearly laid out and labeled.
10) Diagrams are not so large as to inhibit reading and understanding.
11) The developer has reused availa
ble code where applicable.
12) There are no global variables within the system code, except where formally agreed.
13) Preconditions and postconditions are used for all critical VIs.
14) All enumerated types contain meaningful entries.
I have other guides too, if you're interested. You should also search for "LabVIEW code verification".
From The Software Engineers Guide to LabVIEW by Conway & Watts. This is an excellent book. It's pricey, but worth every penny.
1) All code runs without reported errors.
2) Front panels are well laid out, and inputs and outputs clearly defined.
3) All user facing front panels and user interfaces are clear and obvious as to their function.
4) Each icon is meaningful.
5) Each VI name is meaningful.
6) Each component exhibits strong cohesion and is loosely coupled.
7) All interfaces to components are clearly defined.
8) Each VI has the description section filled in.
9) Each VI diagram is clearly laid out and labeled.
10) Diagrams are not so large as to inhibit reading and understanding.
11) The developer has reused availa
ble code where applicable.
12) There are no global variables within the system code, except where formally agreed.
13) Preconditions and postconditions are used for all critical VIs.
14) All enumerated types contain meaningful entries.
I have other guides too, if you're interested. You should also search for "LabVIEW code verification".
Ray.R
Knight of NI
12-06-2004 07:42 AM
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report to a Moderator
bfarley,
In addition to the items that are listed above, I would include suggestion / recommendation such as:
1. Keep vi / sub-vi to a single function / screen, as much as possible.
2. Use sub-vi for code snippets that could be re-used in other vi's.
3. Use sub-vi's to keep the vi's clean (uncluttered).
3. Document the vi's and sub-vi's.
By including suggestions, you could aim towards re-useable code which is cleaner and more compact.
Documenting the vi's is very important as someone in the future will look at the code again..
Your document is also a good idea to promote good programming practices.
Cheers..
-JLV-
😄
In addition to the items that are listed above, I would include suggestion / recommendation such as:
1. Keep vi / sub-vi to a single function / screen, as much as possible.
2. Use sub-vi for code snippets that could be re-used in other vi's.
3. Use sub-vi's to keep the vi's clean (uncluttered).
3. Document the vi's and sub-vi's.
By including suggestions, you could aim towards re-useable code which is cleaner and more compact.
Documenting the vi's is very important as someone in the future will look at the code again..
Your document is also a good idea to promote good programming practices.
Cheers..
-JLV-
😄
