Studying a Big LabVIEW program

[jyang72211]

In the past, when I had a to modify a big and messy program (with only 2% of documentation), I will study it without a set method, and when I have an adaquate understanding of the program, I would re-code it from scartch, since the original program is messy.

Right now, I am looking a piece of code that is big, but not too messy (just sort of messy and with ouly 2% of documentation).  I think I can understand the whole program if I have the right approach to it.  I need to come up with the right method to understand the program, so that I don't get too frustated and quit my job :).  Below is my approach, please comment and also let me know what's your approach.

1. Understand the flow of the program

2. Clean up the block diagram.

3. Go through each subvi and document each of them.

4. Understand how the program interact with input and output

[Taki1999]

---

@jyang72211 wrote:

I think I can understand the whole program if I have the right approach to it.  I need to come up with the right method to understand the program, so that I don't get too frustated and quit my job :).  Below is my approach, please comment and also let me know what's your approach.

1. Understand the flow of the program

2. Clean up the block diagram.

3. Go through each subvi and document each of them.

4. Understand how the program interact with input and output

---

This looks like a pretty good approach.

I think there's actually a Refactoring Checklist in the LabVIEW Core 2 training materials.

This webcast may be helpful too.

NI Webcast on inheriting code

[JÞB]

I usually start with the GUI. Document tip strips  What can the user DO?. 

I/O next (What resources - files- hardware etc...) does the program interact with?  Create action engines for each resource and the code just got a lot cleaner since, encapsulating the I/O just untwisted many bad data structures.  existing subvis next.  Do they make sense? if so document em- else re-work the functions into locically related groups.  the rest flows pretty easy from there.

Lastly- wash your brain out with soap for all the cursing you thought at the developer who wrote that pile of ... remember you once wrote bad code too!

[P@Anand]

---

@Jeff Bohrer wrote:

Lastly- wash your brain out with soap for all the cursing you thought at the developer who wrote that pile of ... remember you once wrote bad code too!

---

Good said Jeff. When I see my first simple application still can't imagine how that worked (LabVIEW makes all these magic) as time went I tried doing neat readable code but still trying to learn an effective way. Thats why I always suggest people about the changes they can make to improve ( As you gave me for mt last post).

🙂

[jyang72211]

Ha, I need to buy a lot of soap.

[johnsold]

I agree that you got some good advice.

If the existing program works, make sure that you have about 3 copies, some of which are hidden in the bottom drawer of your desk, before you start modifying anything.  Having a working version to compare to the modified and improved version can be very helpful.

Also talking to the people who have used the original program can be very helpful in understanding what it actually does (compared to what you were told it was expected to do).  It can be easy to fool yourself that the program works the way you would like it to rather than seeing what it actually does.

Lynn

[OregonGumby]

If you don't have a source code repository, I advise you to get one even if you are the only programmer.  Perforce and Subversion are the most popular choices.  Check your code in often.  It gives you the freedom to know that you can make changes and be able to back them out if you break something.

[MoReese]

Source code repository???  Not me.  You haven't truly lived unless you walk a tight rope over a meat grinder without a safety net!  Gettin' your boys caught in a meat grinder...That's how I want to go out.  Live a little!  What's the worst....OK, I'll admit it.  I am the only programmer and I back mine up regularly.