LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Best approach to dealing with someone else's sphagetti code with no documentation

Hello LabVIEW gurus,

I am just given a few software tools to add functionality and rewrite, each of which is a big spaghetti mess and each tool has 100+ vis all sphagetti, these tools control a very complex machine talking via seria, parallel, ethernet, 485 etc. and there is barely any documentation of the logic or the implemetation of the source code / what the subvis do. 

 

what would be my best approach to understand this mess and recreate it in a structured way faster. it has lot of old sequence structures and just plain bad style of programming.

 

any help is highly appreciated

 

Thanks all

0 Kudos
Message 1 of 10
(3,548 Views)

Run for your life...

 

Believe it or not, I have found the Block Diagram Cleanup often helps in these situations.  Tends to clean up a lot of the weird wiring and make things more linear looking.

 

Other than that, I find it best to just cleanup as you go while you study the code.  Make sure you are using source code control, just in case you break something.  Always test before you touch any code and test afterwards to make sure you didn't break anything.  Add in the documentation based on your understanding.  Put in questions for things you don't understand.


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 2 of 10
(3,533 Views)

Run for your life...

 

is good advice!

 

Not only use source code control but make about three copies of the original (*mostly working*) code and move at least two of those off line in a read-only format. Then do not change any of those copies but make another copy to work on.

 

Figuring out what the code does is the most important part of what you will be doing.  Not just what is is supposed to do but what it actually does. I had one of those messes once where I found several bugs in the original code which made it do things which the users said it should not do - but they were so sure that it worked the way they wanted that fixing the bugs made them unhappy.   If the code says that 2 + 2 = 3.8, but the devices coming off the test rig satisfy marketing and the customers, then you must be very, very careful about correcting the math.

 

Lynn

Message 3 of 10
(3,517 Views)

Sometimes, I like to use the hierarchical view of the project. It helps about the understanding. Sometimes...

That's just an advice.

0 Kudos
Message 4 of 10
(3,498 Views)

OK, you've been practicing this craft for at least 6 years I won't treat you as a newbie.

 

The last solution I delivered was "%75 functioning" when I inherited it.  It was good code!  "Good"  With some nifty custom animated UI controls that I would not like to duplicate (Yet, meaningless to the user! the point of the system was to AUTOMATE it so the user could walk away and do something productive)  Less than %1 of that code was refactored into the deliverables.

 

What it had was six parallel loops- it needed 6 QMHs and a bunch of plugins (Actors) keyed to seven dynamic events.

 

Get the "User Story"  Users often want something much simpler than what you want to deliverSmiley Wink

 

If you have a Tab Control on the main GUI- you probably are wrongSmiley Surprised (I HATE Tabs- they confuse users and hide the subject task at hand)

 

If you need "Engineering Support" there is no reason a project MUST contain only one app build specSmiley Wink 

 

Draw up the sections of code that do not depend on each other.

 

Figure out what would be the best method of communicating between those section (And WHO is in charge) The Synchronization palatte could be a good friend here.Smiley Surprised

 

USE established design patterns! They WORK.

 

If you still feel like running away, ask for help from a local Certified LabVIEW Consultant... They can be found on the partner locator.


"Should be" isn't "Is" -Jay
Message 5 of 10
(3,489 Views)
Listen to Jeff, he is a man who knows where of he speaks! Lynn's comment about "2+2=3.8" is excellent too...

One small additional point is to remember that because you don't know ahead of time exactly what the code does or how it does it, refactoring will be a learning process where you are really trying figure out what the other developer (or developers -- true train wrecks are seldom solo efforts) were thinking.

Consequently, refactoring should be done iteratively. Fix a few really nasty things and make sure it still works the same way it did before. If it is not acceptable, repeat the process as needed. And don't be afraid to backup and rework things you already addressed -- remember: refactoring is a learning process.

Finally, cleaning things up can sometimes make things momentarily worse. For example, I have found that replacing stacked sequences with flat ones (auto grow on all surrounding structures on) ;is often a good first step -- but can for a while really blow-up block diagram size.

Mike...

Certified Professional Instructor
Certified LabVIEW Architect
LabVIEW Champion

"... after all, He's not a tame lion..."

For help with grief and grieving.
Message 6 of 10
(3,445 Views)

Another thing to keep in mind, if you even begin to consider rewriting the entire thing, is that there are probably a bunch of corner-case issues that were already solved.  They'll look like pieces of code that don't belong, and they'll laugh at you later as you scratch your head wondering why your CAN device occasionally transmitts what appear to be malformed messages with an ArbID of zero and you handle it the same way Mr. Spaghetti did.  That reminds me, I need to go comment some code...

Jim
You're entirely bonkers. But I'll tell you a secret. All the best people are. ~ Alice
For he does not know what will happen; So who can tell him when it will occur? Eccl. 8:7

Message 7 of 10
(3,426 Views)

If your task is only to ADD things, you might be interested in Steve's recommendation here.

 

Norbert

Norbert
----------------------------------------------------------------------------------------------------
CEO: What exactly is stopping us from doing this?
Expert: Geometry
Marketing Manager: Just ignore it.
0 Kudos
Message 8 of 10
(3,415 Views)

And Do not forget about using the VI Analyzer TK!  It can reveal several obvious sources to clarify code that "Stinks" A lot of skull sweat went into that framework and it has signifigant value!


 

@Norbert_B wrote:

If your task is only to ADD things, you might be interested in Steve's recommendation here.

 

Norbert


 

(Inside joke ahead)

Ah, That explains the TDMS File Viewer!

 

 

Spoiler
You really should run that through the VIA....:smileymad
Spoiler
Spoiler
How do you unspoiler?  Ah well  I'll hope a moderator can leave only the first comment "spoiled"
Spoiler
Note the quote from the link "The Code we inherited might have been "richly obfuscated."" "richly Obfuscaed code was a code review term used for code written by your boss... The VIA would call it something else.

"Should be" isn't "Is" -Jay
0 Kudos
Message 9 of 10
(3,355 Views)

thanks all,

i will follow your suggestions

0 Kudos
Message 10 of 10
(3,245 Views)