I also like the idea of never even allowing a diagram to go beyond one screen while you program- don't even give the windows scrollbars... Bit of a pain when you move from a 27" monitor back to a 19" of course 😉 Although I'd probably contend the diagram window should be limited to about the size of a 19" monitor regardless- that's what driven case (not stacked sequence!) structures are for... 😉
Well I want the ability to prototype code that may not be all that clean and adhere to the one screen rule initially. Then optimizing cleanup for one screen/one direction might allow us to get back to a 'cleaner' diagram.
My two cents is that if your code is multiple screens wide and multiple screens tall you have bigger issues than worrying about the tool cleaning up too much of your code. My general rule is to write code so that a diagram will only require scrolling in one direction; if it must be larger than what fits in one screen.
For text languages:
Would it be acceptable to randomly insert blank pages so you'd need to scroll up/down to see the adjacent code?
Would it be acceptable to randomly insert extra tabs so you'd need to scroll right and left to see the adjacent code?
Would it be acceptable to put all of the code in the main and have no function calls?
Why should special tools be created to promote these programming styles for graphical programmers?
Yes, programming styles that view the block diagram as an endless prarie that needs to be filled and those that refuse to make use of subVIs are two of my pet peeves.
I figured the LabVIEW police would be out in full force on this one. I have been developing for 20 years.....There are unavoidable situations where speed of development for prototyping trumps style. If you are going to have diagram cleanup at all, why not add some useful options to it?
Any idea that has received less than 3 kudos within 3 years after posting will be automatically declined.