LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

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

Quite often I come across code written by someone else who is long gone and it is my task to understand what is going on under the hood. Oftentimes no comments, sometimes with, but even then they can sometimes be cryptic. 

 

I suspect most of us know the popular tools:

 

  • Highlight Execution
  • Probes
  • Breakpoints

 

I want to pick your brains!

 

What tricks have you learned over the years to better facilitate this task? 🤔

Message 1 of 18
(1,861 Views)

Many times, the code is awful.  In such cases usually it's better to throw it away and start over.  Trying to understand something that's demented twisted mess is a waste of time.

"If you weren't supposed to push it, it wouldn't be a button."
Message 2 of 18
(1,833 Views)

Some want to make our lives easier, some don't. In the case of the latter, I have seen some code in an absolute spaghetti mess, without any SubVIs but it works a charm, it took me a month to thoroughly understand the logic behind the code to recreate it in a better-structured way.

 

A common issue in programming is that some would go to vast lengths with convoluted logic to achieve a simple piece of code which you would not guess until you understand close to everything.

 

My technique is to start from the simpler part of the code so that I still have some patience and I have some satisfaction that I am making progress.

Santhosh
Soliton Technologies

New to the forum? Please read community guidelines and how to ask smart questions

Only two ways to appreciate someone who spent their free time to reply/answer your question - give them Kudos or mark their reply as the answer/solution.

Finding it hard to source NI hardware? Try NI Trading Post
Message 3 of 18
(1,831 Views)

Yep, you got me there. I've not used anything other than the trusty trio. . .

 

I look forward to seeing other people's ideas & techniques.

 

Great idea to ask!👌

Message 4 of 18
(1,825 Views)

Over time, after seeing a lot of awful codes, you will be able to quickly guess what the programmer had in mind and you would save time but there is always a particular technique (worse) that you've not come across that will still take your time to understand.

 

Santhosh
Soliton Technologies

New to the forum? Please read community guidelines and how to ask smart questions

Only two ways to appreciate someone who spent their free time to reply/answer your question - give them Kudos or mark their reply as the answer/solution.

Finding it hard to source NI hardware? Try NI Trading Post
Message 5 of 18
(1,820 Views)

@paul_cardinale  ha scritto:

Many times, the code is awful.  In such cases usually it's better to throw it away and start over.  Trying to understand something that's demented twisted mess is a waste of time.


In principle I agree. The problem is that it's often very difficult to get good specifications. Many times, all you get is the old software and a verbal description (or equivalently a handful of text lines). So, in any case, you are forced to understand the old software before starting to re-code.

What I did in some cases while analyzing the old code is to try improving the readability with no functional modifications (or with very small, very careful changes), essentially just repositioning the various elements in a more sensible way. This is time consuming, of course, but may render the code more digestible.

 

Paolo
-------------------
LV 7.1, 2011, 2017, 2019, 2021
Message 6 of 18
(1,781 Views)

Deleting (!) comments and labels might be surprisingly useful. In LabVIEW, this even extends to VI Icons. If you need tools to understand the code, it is probably in a state where the written documentation is outdated, misleading or plain wrong.

Message 7 of 18
(1,774 Views)

@LLindenbauer wrote:

Deleting (!) comments and labels might be surprisingly useful. In LabVIEW, this even extends to VI Icons. If you need tools to understand the code, it is probably in a state where the written documentation is outdated, misleading or plain wrong.


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.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
Message 8 of 18
(1,727 Views)

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

 

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

Message 9 of 18
(1,691 Views)

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

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 10 of 18
(1,678 Views)