What are your go-to tools for understanding existing code?

[paul_cardinale]

---

@billko wrote:

---

@B_Strange wrote:

Ah yes, block diagram cleanup can bring huge gains! Thanks for the reminder.

But not auto block diagram cleanup (in my experience). 

---

If the cleanup tool improves the look of your block diagram, you need to seriously rethink your block diagram design.  😄

---

This takes the total wire length / 100, then adds the number of bends.  Runs the cleanup tool, then calculates again.  Ratio of the two numbers tells how bad it is.

Not super accurate, but it's something.

[thols]

---

@paul_cardinale wrote:

...

---

This takes the total wire length / 100, then adds the number of bends.  Runs the cleanup tool, then calculates again.  Ratio of the two numbers tells how bad it is.

Not super accurate, but it's something.

---

Why is it password-protected? Do I dare to run a VI that I don't know what it does? Where is the VI from?

But an interesting measurement anyway.

[paul_cardinale]

D'oh!

I meant to remove PW protection.

Here.

[stevem181]

Bookmarks can be a useful tool especially for larger projects. The Bookmark Manager makes it easy to jump to related items quickly.

Use Bookmarks to document your progress and to highlight areas that will require more investigation. 

Once you get used to them you will find many use cases. 

"Comments are a lie waiting to be told.", Author Unknown

[Intaris]

If the code is complicated and hard to understand, I will often look for common pieces of code (no matter how small), create sub-VIs out of them and replace the code with sub-VIs. This gives them some sort of structure, where I can begin to locate regular operations as opposed to clumps of messy LV code. Just having some pieces of recognisable common code with icons makes reading a lot of code much easier. When the difficulty of understanding code increases with the square or the cube of the number of nodes, reducing even a few little pieces of code like this can help flatten the curve into getting familiar with what's going on.

Once the code is kind of readable, I start following the actual code progress mentally, before even starting to run the code. Once I feel like I've understood what's going on, I'll often actually revert to the original code for testing, and when I see how it behaves, re-introduce the sub-VIs one by one making sure they work as expected.

Of course this depends greatly on the scope of the code being investigated.

[Yamaeda]

---

@crossrulz wrote:

The only thing worse than no documentation is wrong documentation.

When I inherit "ancient" code, I refactor to understand it.  Breaking things into subVIs, improving that portion (subVIs help a lot with regression testing).  Of course, make sure this code is locked away in a Source Code Control before doing anything to it.

---

That's a great way to gain understanding of old code. Of course while adding comments to help remember what you've deciphered so far. Just changing names of controls and wires can be quite helpful, i've had much code with Data this and Value that instead of useful naming.

[AeroSoul]

I don't think cleanup tool helped me even once, usually it makes it worse. I do use it for forum examples tho 😄

[AeroSoul]

---

@paul_cardinale wrote:😄

---

This takes the total wire length / 100, then adds the number of bends.  Runs the cleanup tool, then calculates again.  Ratio of the two numbers tells how bad it is.

Not super accurate, but it's something.

---

Oof, my first large VI has a score of 1000+ ranked as sewage. I feel attacked.

Then again, i checked the VI and it's now totally **bleep**ed because of the cleanup tool... maybe should have warned about that