07-14-2022 02:18 PM
Hello everyone,
My employer would like a standard for how we write our labview code to provide some level of consistency between programs or Sub VIs programmed by multiple individuals. I have stepped up and started putting one together, however I have only been programming in Labview for about a year and still consider myself very much a newbie.
At the moment most of what I written focuses around state machines, using descriptive case names and type definitions, naming the state machine using the subdiagram label, etc...
Would anyone care to share some of the things you think should or shouldn't be in a coding standard?
Thanks!
07-14-2022 02:40 PM
In my experience, most companies who write internal LabVIEW coding standards use the LabVIEW Style Checklist as a template, then add/remove/modify content as it suits their needs.
07-14-2022 05:11 PM
Thanks that is a big head start. If anyone has recommendations that are not already included in the style checklist I would still like to hear them.
07-14-2022 05:54 PM - edited 07-14-2022 06:02 PM
I wrote one for my company and I did in fact start with the list Darren linked, removing things we don't use much or disagreed with.
Other things:
Also, for extra fun, if there's anything that's a pet peeve of yours but it's one of those style choices that can be argued either way, you can add it to the style guideline to make it official. For instance, things like whether camelCase is an acceptable naming scheme for controls or whether LabVIEW supporting spaces means it shouldn't be used.
07-14-2022 06:28 PM
I worked for a place that had a style guide and a design pattern library that complemented the style guide. That particular company was a big labview company so much so that the design pattern library had 1000s of VIs. You could pull an application template from the design pattern library and it would already have all the QMH messaging, custom UI objects with company logos, I/O for any thing you could think of and all sorts of other stuff already baked in. Any way it was pretty nice to have that library. If you ever wondered how something was supposed to be done you could usually find an example in the library.
07-14-2022 06:51 PM
I would also add some guidelines regarding icons. It is extremely helpful if there are standards to the icons including colors for different re-use libraries. May want to discuss how and when to make your code into more general purpose re-use libraries. If you plan for the long term over time you should be building up a solid set of re-use libraries which makes application design easier over time. More stuff will be picked up from the re-use libraries or project templates. Then your main focus can be on the particulars of that application. You also have confidence in the underlying code since it has been used on multiple projects. It also makes it easier to debug and work on other applications that you have developed since they all have a similar structure, or at a minimum a small set of frameworks.
07-15-2022 09:24 AM - edited 07-15-2022 09:25 AM
I did a presentation about a year ago on Code Review and VI Analyzer for our User Group.
It focuses mostly on the process that an organization can go with to help improve code quality. This can involve the VI Analyzer, code reviews, check lists, and mentoring.
Unofficial Forum Rules and Guidelines
Get going with G! - LabVIEW Wiki.
16 Part Blog on Automotive CAN bus. - Hooovahh - LabVIEW Overlord
07-15-2022 10:21 AM - edited 07-15-2022 10:25 AM
@Evelyn_Richards wrote:Would anyone care to share some of the things you think should or shouldn't be in a coding standard?
The ten of us never needed a style guide.
Not that it was never tried to make one, but most content would be trivial (and ignored) or opinioned (and ignored).
Most reasonable rules have reasonable exceptions. Intent is very important. For instance, I don't mind wiring behind a structure (even though it 'isn't clear'), when the alternative is worse (a big wire mess). The rule is there to improve clarity (which is an opinion), but sometimes it makes things less clear (another opinion).
However, 'rules' (I'd prefer recommendations with reasons and costs when ignored so people can make an educated choice) for naming, icons, project structure, class hierarchy on disk, etc. do make sense.
The literal "rules to wire by" seem (to me) the least important.
I am thinking about 'hard limit' rules. Things like:
+ error in should connect to error out (except for error handling code)
+ child methods should be removed when they only call parent method
+ 4X4X4 connector pane
+ no builds in source code control
But if you have 200 rules like this, nobody will read it, unless you put it in a comic.
07-15-2022 11:28 AM
Much of this is specific to my company, but you might find some of it useful.
07-15-2022 11:32 AM
wiebe@CARYA wrote:
@Evelyn_Richards wrote:Would anyone care to share some of the things you think should or shouldn't be in a coding standard?
The ten of us never needed a style guide.
Not that it was never tried to make one, but most content would be trivial (and ignored) or opinioned (and ignored).
Most reasonable rules have reasonable exceptions. Intent is very important. For instance, I don't mind wiring behind a structure (even though it 'isn't clear'), when the alternative is worse (a big wire mess). The rule is there to improve clarity (which is an opinion), but sometimes it makes things less clear (another opinion).
However, 'rules' (I'd prefer recommendations with reasons and costs when ignored so people can make an educated choice) for naming, icons, project structure, class hierarchy on disk, etc. do make sense.
The literal "rules to wire by" seem (to me) the least important.
I am thinking about 'hard limit' rules. Things like:
+ error in should connect to error out (except for error handling code)
+ child methods should be removed when they only call parent method
+ 4X4X4 connector pane
+ no builds in source code control
But if you have 200 rules like this, nobody will read it, unless you put it in a comic.
I would read that!!!