LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

How to document LabVIEW program?


@RavensFan wrote:

Why resurrect a 16 year old thread?


Well, there's no accepted solution Smiley Wink.

0 Kudos
Message 11 of 19
(435 Views)

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.

Message 12 of 19
(433 Views)

wiebe@CARYA wrote:

@RavensFan wrote:

Why resurrect a 16 year old thread?


Well, there's no accepted solution Smiley Wink.


"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

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 13 of 19
(425 Views)

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

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 14 of 19
(422 Views)

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. 

0 Kudos
Message 15 of 19
(201 Views)

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

billko_0-1614790330709.png

(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..."

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.
Message 16 of 19
(195 Views)

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

Message 17 of 19
(179 Views)

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

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.
Message 18 of 19
(171 Views)

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

Message 19 of 19
(145 Views)