Clean Up Selection messes up Code in hugh Block Diagram

[jusaca]

Currently I have the task to analyse, clean up and reorganize a terrible messed up program, that was created over many years from a lot of "developers".

The size of the Block Diagram of the Main VI is just insane, you can scroll in every direction like for ever, with a lot of stacked sequence in sequence in sequence...

Well, I like to use "Clean Up Selection" for small parts of the code if there is just one big mess, so that I am able to see what is happening there. It just a nice starting point.

But here my problem begins: If I use "Clean Up Selection" in this hugh VI for only a small selected part, it nearly always messes up some other part of the code! After the Clean Up the VI suddenly isn't executable any more and there are some broken wires or open ends or something like that on a totaly different part of the code!

I don't understand what is happening there and it really is annoying... I know that it is hard to help without me providing you some example code, but please understand that I'm not allowed to share the code. I just hope, that this may be a known problem with a known cause and work-around?

Best regards

[wiebe@CARYA]

---

@jusaca wrote:

Currently I have the task to analyse, clean up and reorganize a terrible messed up program, that was created over many years from a lot of "developers".

The size of the Block Diagram of the Main VI is just insane, you can scroll in every direction like for ever, with a lot of stacked sequence in sequence in sequence...

Welkom to the club! We feel your pain...

---

jusaca wrote

Well, I like to use "Clean Up Selection" for small parts of the code if there is just one big mess, so that I am able to see what is happening there. It just a nice starting point.

But here my problem begins: If I use "Clean Up Selection" in this hugh VI for only a small selected part, it nearly always messes up some other part of the code! After the Clean Up the VI suddenly isn't executable any more and there are some broken wires or open ends or something like that on a totaly different part of the code!

I don't understand what is happening there and it really is annoying... I know that it is hard to help without me providing you some example code, but please understand that I'm not allowed to share the code. I just hope, that this may be a known problem with a known cause and work-around?

The clean up code cleans up the selection, but probably extends to connected wires. So if anything in your selection has wires outside the selection, these are included in the clean up.

Maybe you can try putting a sequence structure around parts, do the clean up, and then remove the sequence structure? Probably, there isn't room to place the structure, but it might help...

Usually cleaning up is just a small part of the problem.

I usually:

1) Go through the code and fix obvious stupidities.

2) And also obvious optimizations. Old code can usually be clean up quite a bit by replacing arrays in shift registers with the appropriate index option (concatenate is relatively new so is conditional).

3) 1 and 2 usually have no relevance, but it feels like making progress, and you get to know the program.

4) Use scripting to fix really stupid mistakes. I've seen programs with 20 different enums "typedefs", but non of them where typedefs. Used scripting to replace 450 enums with the new typedefs. This is usually a nice break from doing it manually.

5) At some point, you need to categorise code. I'd start making classes from the obvious candidates first.

6) Or figure out what it should do and start over (optionally with reusing the obvious block from 5).

Guess there's not much else to do...

[Bob_Schor]

I've done this several times with large LabVIEW Projects that had gotten seriously "out of hand", with huge Block diagrams (one I printed out half-size, and it took 20 pieces of paper taped together to see it all).  Here's what I recommend:

• Start Over!  Do NOT try to "rescue" any code, but use the existing code to guide you in the next step.
• Write Documentation!  Determine as precisely as possible what needs to be done, with any constraints that may apply.
• Try to come up with a simple (or "simpler") data structure for your Project.  Feel free to abandon "the old way" that data were being stored (it is often easier to write "data translators" or "reformatters" than to continue using inappropriate or confusing/awkward/illogical Data Structures).
• Write (some) Documentation before starting to code.
• Use good LabVIEW Coding Practices.  This includes:
  • Use Version Control (Subversion, Mercurial, Git, Perforce, Something Else).
  • Use LabVIEW Project.
  • Use sub-VIs and TypeDefs liberally.
  • Keep Block Diagrams to one (reasonable) screen (say no more than 1920 x 1080, or even smaller).
  • Consider using LVOOP and Classes (this is an area I'm still exploring ...).
• Revise Documentation as you code.  The urge to code is much stronger than the urge to document, but don't let the Documentation lag too far behind ...

Bob Schor

[jcarmody]

[...] Start Over [...]

I can't imagine how this'll turn out...

Years of developers adding years of modifications results in the so many corner cases having been handled that the best of us have little chance of capturing all of them in any timely fashion.  The worst of us will fail miserably.

---

---

[...] I have the task to analyse, clean up and reorganize a terrible messed up program [...]

Unless you're given a lot of time to accomplish this, you should refuse the task.  There's no immediate upside and a ton of downside.

https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/

[Bob_Schor]

Yes, I largely agree with you and Joel ...

Bob Schor

[Hooovahh]

@jcarmody wrote:

[...] Start Over [...]

I can't imagine how this'll turn out...

I've had way too much success throwing old crap out and starting over, than others have said I should.  Many projects that I've re-written where 1 or 2 guys worked on it for a year or two struggling to get it to work then they would move on before the project was finished (or work Visa's ran out) and I'd be called in.  In a week I would have a mostly working test system, and in another week have it pretty much perfect.  This has happened about 6 times in three years at the the last company I was at.  Every test system that just needs to functionally check hardware has so many of the same core elements that I just made some scripting code that would generate the project along with the logging module, pass fail testing, a basic sequencer, error handler, configuration, UI, reporting, and a few other things.  I have yet to regret a re-write project, but often times think about the band-aid'ed solution that is still in the wild like a time bomb that might need my attention.  I know I've heard many experts say don't throw it away and instead fix what's there, but none of the projects I've thrown away were worth fixing.

[wiebe@CARYA]

If the time constraints are good, I don't mind to much to refactor to something completely new.

It's almost meditative, probably a bit like raking a Japanese rock garden. Clean up the code, clean up your mind. Should probably start with my desk...

[jcarmody]

---

@Hooovahh wrote:

@jcarmody wrote:

[...] Start Over [...]

I can't imagine how this'll turn out...

I've had way too much success throwing old crap out and starting over, than others have said I should. 

Remember that I said:

---

jcarmody wrote: [...] the best of us have little chance of capturing all of them in any timely fashion. 

You're well situated among the best of us. I even feel silly saying "us".