How to document LabVIEW program?

[wiebe@CARYA]

---

@RavensFan wrote:

Why resurrect a 16 year old thread?

---

Well, there's no accepted solution .

[wiebe@CARYA]

You typically don't want to document anything after the fact.

In OO (but it also works without it):

+ Analyze the problem (OOA)

+ Design a solution (OOD)

+ Implement the solution (OOP)

Of course, during OOA, OOD and OOP, there could be test code to show proof of principles, tests, driver development, etc. This is not a linear process per se. But when done properly, the Design will be the documentation of the program.

Documentation after the fact can be very hard, especially when there is no coherency in the program. This has nothing to do with using LabVIEW, the same applies to C, C++, Java, Python or whatever.

[Ben]

---

wiebe@CARYA wrote:

---

@RavensFan wrote:

Why resurrect a 16 year old thread?

---

Well, there's no accepted solution .

---

"Solutions" had not been invented yet.

For that matter we may not have had the ability to even post images when this thread was alive.

Ben

[Ben]

---

wiebe@CARYA wrote:

You typically don't want to document anything after the fact.

...

Documentation after the fact can be very hard, especially when there is no coherency in the program. This has nothing to do with using LabVIEW, the same applies to C, C++, Java, Python or whatever.

---

Agreed. Very long ago I had advised;

"Design first, write second".

Ben

[jdean781]

after developing software for 20 years - maybe 10% write clean maintainable code. In any language. Maybe 5% add some comments. Most of the time you have to reverse engineer it and/or run in debug mode. The really tricky part is interfacing with embedded devices where you may need a subject matter expert. 

[billko]

---

@jdean781 wrote:

after developing software for 20 years - maybe 10% write clean maintainable code. In any language. Maybe 5% add some comments. Most of the time you have to reverse engineer it and/or run in debug mode. The really tricky part is interfacing with embedded devices where you may need a subject matter expert. 

---

Everyone who needs to modify code that I've worked on says it's so easy to figure out because... mostly self-documentation techniques.  Front panel object labels that make sense, VI's with sensible names and brief descriptions, making use of subdiagram labels and also - as a bonus - making visible the case structure label and using it as an overall description:

(The subdiagram label is just a generic placeholder in this example.)  If it's not an enum driving the case structure, I'll give a more general description, like "If current is too high (Amps >= 5) then..."

[wiebe@CARYA]

The importance of naming in programming | The Man in the Arena (carlalexander.ca)

Was it Joel Spolsky that said (or quoted)" "90% of programming is choosing correct names"? Can't find it...

[billko]

---

wiebe@CARYA wrote:

The importance of naming in programming | The Man in the Arena (carlalexander.ca)

Was it Joel Spolsky that said (or quoted)" "90% of programming is choosing correct names"? Can't find it...

---

LOL fretting with what to name a control is one of the hardest things to do!  (At least for me.)

[wiebe@CARYA]

---

@billko wrote:

---

wiebe@CARYA wrote:

The importance of naming in programming | The Man in the Arena (carlalexander.ca)

Was it Joel Spolsky that said (or quoted)" "90% of programming is choosing correct names"? Can't find it...

---

LOL fretting with what to name a control is one of the hardest things to do!  (At least for me.)

---

VIs too.

That got easier (for me) with OO. Not exactly sure why. Probably a combination of things: you have a library the VIs are in (the class), there are guidelines, I got more experienced...