LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Writing a Company Labview Coding Standard

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!

Message 1 of 14
(622 Views)

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.

Message 2 of 14
(615 Views)

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.

0 Kudos
Message 3 of 14
(582 Views)

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:

  • What goes in user.lib, instr.lib, etc. and what doesn't
  • How to store things in source control
  • What versions of things are OK to use and when to increment them
  • How to handle people who want to use common external code (OpenG, etc.)
  • How to use the bookmark manager tags (i.e. define common tags and/or restrict their use in shared code so that you don't have 1,000 bookmarks to sort through when you only care about 1)
  • How to use units when naming controls and indicators (cm, mA, etc.)
  • When the radix needs to be shown on constants or controls
  • Agreed upon max sizes for VIs, block diagrams, etc.
    • The linked guide says "no bigger than your screen" but what if one dev programs at 1280x720 and another is using a 4K monitor?  Pick a common denominator.

 

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.

0 Kudos
Message 4 of 14
(574 Views)

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. 

______________________________________________________________
Have a pleasant day and be sure to learn Python for success and prosperity.
0 Kudos
Message 5 of 14
(567 Views)

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.



Mark Yedinak
Certified LabVIEW Architect
LabVIEW Champion

"Does anyone know where the love of God goes when the waves turn the minutes to hours?"
Wreck of the Edmund Fitzgerald - Gordon Lightfoot
0 Kudos
Message 6 of 14
(560 Views)

I did a presentation about a year ago on Code Review and VI Analyzer for our User Group.

 

https://youtu.be/6yMedKDr-Ik

 

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.

0 Kudos
Message 7 of 14
(473 Views)

@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.

0 Kudos
Message 8 of 14
(449 Views)

Much of this is specific to my company, but you might find some of it useful.

"If you weren't supposed to push it, it wouldn't be a button."
Download All
0 Kudos
Message 9 of 14
(437 Views)

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!!!

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 10 of 14
(434 Views)