Writing a Company Labview Coding Standard

[Jay14159265]

---

@paul_cardinale wrote:

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

---

Thank you for this, it is a great style guide. I had a good laugh at the Coding section where it gives Guideline vs Reason and the first one is: 

Don't create obscure or hard to follow code

Other people will have to deal with your code.

 We are adopting that as out first and only rule from now on! 

[paul_cardinale]

---

@Jay14159265 wrote:

---

@paul_cardinale wrote:

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

---

Thank you for this, it is a great style guide. I had a good laugh at the Coding section where it gives Guideline vs Reason and the first one is: 

Don't create obscure or hard to follow code

Other people will have to deal with your code.

 We are adopting that as out first and only rule from now on! 

---

Maybe you'll like this.

[Jay14159265]

---

@paul_cardinale wrote:

---

---

Maybe you'll like this.

---

Yes, I do like that. Sometimes I work with people that think they are real artists. I wish I could hand them something like this. 

[Evelyn_Richards]

---

Don't create obscure or hard to follow code

Other people will have to deal with your code.

 We are adopting that as out first and only rule from now on! 

---

Yes, this is why I have been asked to write a coding standard. A former employee's code was soo bad that when I was hired they asked me to write new programs from scratch, even though I had less than a year of experience with labview at the time. 

My code probably isn't the greatest but it is readable, commented, and linear flow

I appreciate all the comments!

[carlos_camargo]

---

@paul_cardinale wrote:

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

---

Thanks for sharing your guidelines.  I like that they're brief and readable.

Hahaha!  Your "Bad Icon" is my "best practices" Icon😉.  To me it's wasteful to spend time looking for whatever little picture best communicates what I'm trying to communicate.  Those will always be ambiguous and open to misinterpretation.  The name of the VI already explains what it does, because I choose appropriate names, the icon should therefore reflect that name directly. I do agree with the use of the template bar at the top for class (or DQMH) items, but only because it comes for free.  That part is text for a reason.

"Don't create obscure or hard to follow code" - this leaves a lot of room for interpretation, you know "one man's wine is another man's poison" and all that.

I've found that one major impediment to code reuse is finding what already exists in "common".  Because, how are you supposed to find it?  Do you guys use tags when you create code and put it into common?  Is there a team that adds tags?  I didn't see anything regarding how to put code into "common".

I like your other guidelines and especially the instruction on Rings & Combo boxes.

[Kyle97330]

---

@carlos_camargo wrote:

---

Hahaha!  Your "Bad Icon" is my "best practices" Icon😉.  To me it's wasteful to spend time looking for whatever little picture best communicates what I'm trying to communicate.  Those will always be ambiguous and open to misinterpretation.  The name of the VI already explains what it does, because I choose appropriate names, the icon should therefore reflect that name directly. I do agree with the use of the template bar at the top for class (or DQMH) items, but only because it comes for free.  That part is text for a reason.

---

The "Icon as pictures" is an OK idea if you're making a set of VIs to publish externally.  The icon is the first thing people see, and if you're marketing it you want to leave the idea open that not everyone speaks English who uses LabVIEW, so a bunch of pictorial icons can be great for that.  The posted guidelines after the icon examples do specifically mention multi-language support, so that could be part of it.

However, if you're keeping it in your company, especially if everyone in your company is an English speaker, and this is one icon out of 500 or 1000 you need to make for a project... use words.  Hand-crafting 1000 tiny ideograms from scratch will waste time and just make it more annoying to go through your code.

As for "Don't create obscure or hard to follow code", one of the other devs where I work has a saying.  "Write your code like the programmer who works on your project next is an axe murderer and knows where you live".

[Basjong53]

---

@paul_cardinale  ha scritto:

1. Names of drivers should be based on function, not the model of the instrument (e.g. “PS” not “N6700”).  Also avoid names that are too long, as they will appear in property nodes and long names will take up extra space on the block diagram.

    

---

Just a a side note, you can change the name that appears on property nodes of classes in the class properties. So you don't have to worry about your classes having a name that's too long.