Good coding practices

[Ben]

Re: ms timer values

You can subtrat the values to meassure a time difference and since it is unsigned the math works out even durring the roll-over. In most cases I use the system time instead.

Ben

[RavensFan]

---

Guruthilak wrote:

1) The constsnts like the array constant (0E 00 06) along with the "Byte Array To String" must be kept outside the while loop. Since for every iteration the same conversion is happenning so its a waste of the resource

2) same thing with constant connected to "Wait (ms)"

---

Guru,

Neither of these statements is true.  Since they are constants, they get folded at compile time anyway.  There is no performance hit for conversions.  Moving the constants outside of the loop runs the risk of additional buffer allocations (though it doesn't look like it would happen in these cases for the same reason.

[JÞB]

---

Ravens Fan wrote:

---

Guruthilak wrote:

1) The constsnts like the array constant (0E 00 06) along with the "Byte Array To String" must be kept outside the while loop. Since for every iteration the same conversion is happenning so its a waste of the resource

2) same thing with constant connected to "Wait (ms)"

---

Guru,

Neither of these statements is true.  Since they are constants, they get folded at compile time anyway.  There is no performance hit for conversions.  Moving the constants outside of the loop runs the risk of additional buffer allocations (though it doesn't look like it would happen in these cases for the same reason.

---

RF-

OK I'm going to shamelessly beg you to post a nugget detailing this.  Please, Please... I'm Shameless.  I read gurus post and agreed without reservation out of ignorance.  I learned to keep as many operations outside of loops as possible, but that appears to not be the hard and fast rule.  Folding? Buffer allocations?  (OK I've seen the "Show constant folding " But what is it and how does it help my code?

[jyang72211]

Hi

Jeff B. - can you clariy on the comestic problem on the error in and error out?  I didnt' get that.

Another question: In regards to the descriptons of controls and indictors, it is need for just the main VI?  Do the subvi needs that as well?  What is acceptable?

Yik

[smercurio_fc]

---

jyang72211 wrote: 

Another question: In regards to the descriptons of controls and indictors, it is need for just the main VI?  Do the subvi needs that as well?  What is acceptable?

---

There is no single answer to this other than to say document it unless it's so bloody obvious that a 5-year old could understand it.

That said, normally controls at the main VI get documented for the user interface. SubVIs are used by a programmer, so typically the VI's documentation is the first place you'd look. If there is so much documentation that it would require a 50" monitor to display it all then it makes sense to break it up and put the documentation that's specific to a control with that control. At least, that's my opinion. 

[smercurio_fc]

---

Jeff Bohrer wrote:

RF-

OK I'm going to shamelessly beg you to post a nugget detailing this.  Please, Please... I'm Shameless.  I read gurus post and agreed without reservation out of ignorance.  I learned to keep as many operations outside of loops as possible, but that appears to not be the hard and fast rule.  Folding? Buffer allocations?  (OK I've seen the "Show constant folding " But what is it and how does it help my code?

---

As with all things, recommendations change over time, especially as LabVIEW changes. Constant Folding. I primarily use LabVIEW 8.2 at work, and constant folding... not so good in that version.

[JÞB]

Quoting from the stye guide pg 5-5

"Creating Control and Indicator Descriptions
Include a description for every control and indicator. To create, edit, and
view object descriptions, right-click the object and select Description and
Tip from the shortcut menu. The object description appears in the Context
Help window when you move the cursor over the object and in any VI
documentation you generate.
Unless every object has a description, the user looking at a new VI has no
choice but to guess the function of each control and indicator. Remember
to enter a description when you create the object. If you copy the object to
another VI, you also copy the description."

So for that point I concur with Smercurio_fc and Really- sure its obvious to the developer during development of the vi (Why "Waste" the time?) When it gets into a larger project with multiple developers or w few day pass between when you build the vi and when you re-use it in a project-- you just saved the wasted time by having the discription and tip right there to refresh your memory.  Like all habits the way you learn first is hard to change.  Expect to grow and develop good habits so they become second nature. 

I had no intention of "picking on you" or sounding grumpy- but you have again shown that you desire to "do LabVIEW Right" and I feel proper documentation is a tremendous benefit. That's my no-so-humble opinion.  And frankly, when I started out I had to learn the hard way-to my great misfortune.

---

Back to the style guide

" Front Panel Checklist
Give controls meaningful names. Use consistent capitalization.

The FIRST item on the checklist....First!  Your FP is the first impression of your work.  Consistant font and consistant capitalization gives the impression of professional, detail oriented workmanship.  You don't interview for a job in torn jeans and shoing poor hygene.  Your FPs are an interview for acceptance of your work.  Although it has no bearing on the code functionality whatsoever, your code WILL be judged on its presentation.

error in(no error) and error out are an exception to the rule of initial caps as are certain key words like in, out , ref, dup, DAQmx, IVI, COM and VISA.  These normally appear as listed.  Luckilly, GUIs typically have these objects outside the viewable portion of the FP.

[JÞB]

---

smercurio_fc wrote:

---

Jeff Bohrer wrote:

RF-

OK I'm going to shamelessly beg you to post a nugget detailing this.  Please, Please... I'm Shameless.  I read gurus post and agreed without reservation out of ignorance.  I learned to keep as many operations outside of loops as possible, but that appears to not be the hard and fast rule.  Folding? Buffer allocations?  (OK I've seen the "Show constant folding " But what is it and how does it help my code?

---

As with all things, recommendations change over time, especially as LabVIEW changes. Constant Folding. I primarily use LabVIEW 8.2 at work, and constant folding... not so good in that version.

---

Thanks!

5.1 for 2yrs

6.1 for 2

7.0-7.1 for 2 more

Got 8.0 And stalled for 4 

Jumped back in w 8.6.1 and early adopted 2009

I missed a bit with the 8.20 to 8.5 jump and I'm still catching up! Time to really pour over the help files of my lessor used versions since I do have 7.1 - 2009+  (and a customer in 6.1)

[Ray.R]

You can include documentation on the block diagram, as well as labels '> my label >'.

See image below:

Message Edited by Ray.R on 03-05-2010 12:47 PM

[Guruthilak]

---

Guru,

Neither of these statements is true.  Since they are constants, they get folded at compile time anyway.  There is no performance hit for conversions.  Moving the constants outside of the loop runs the risk of additional buffer allocations (though it doesn't look like it would happen in these cases for the same reason.

---

You are absolutly right Raven..

I had read about this topic some time back and completely forgot about the same..

Thanks for making me to brush up..

Sorry i could give you only one KUDO....

For others ,there is a link here

To view this constant folding you have to enable the same in ...Tools >> Options >> Block Diagram setting->Constant folding and check the "show constant folding of wires" and  "show constant folding of structures"

Guru