02-26-2019 04:18 AM
@RavensFan wrote:
Why resurrect a 16 year old thread?
Well, there's no accepted solution .
02-26-2019 04:22 AM - edited 02-26-2019 04:25 AM
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.
02-26-2019 07:56 AM
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
02-26-2019 07:58 AM
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
03-03-2021 10:25 AM
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.
03-03-2021 10:54 AM - edited 03-03-2021 10:59 AM
@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..."
03-03-2021 11:43 AM
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...
03-03-2021 12:09 PM
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.)
03-04-2021 02:38 AM
@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...