I'm new to writing to forums etc. so forgive my approach if it seems a little different.
I would be delighted if I can offer a discussion that is helpful. I have worked for a number of years without being monitored, designs have worked ok but I don't get expert feedback. I want to find a way of learning better more efficient techniques, other than from youtube and courses.
I am working on various test sequencer projects (RF test equipment using RS232, GPIB etc) with someone else's code.
Here are some of my questions:
Are there any drawbacks from using "DATA HIWAYS" (Clusters of clusters on shift registers of a state machine). which contain all/over aprox 100 controls.
So i pick up someone else's design and its really big, spanning 6x the screen, wires everywhere.
I decide to keep the functionality but refactor the code to one screen. I create a state machine that allows me to break down the process into single steps, I am thinking I want to practice working with Object Oriented programming but at a much later date, so I plan to let the project "evolve gradually toward OOP", so I try to make each VI very similar, similar to a class method with error in/out and class in/out and maybe one other terminal.
I notice that each VI has all data available and most processes are unbundling or bundling with a simple process. No untidy wires, a simple testable step, but a heck of a lot of data choice.
Yes I could access as much as possible via references, but would it be better to limit the data.
I'm not experienced with OOP, but i'm thinking it would be an easier step to let all the data travel down the root class wire, and use dynamic dispatching instead of case structures.
In general I don't have the time to rebuild from scratch and the functionality of the code is ok anyway.
Any comments would be gratefully received.
First of all, welcome.
I don't see a problem with it. Quite often when working with existing code, it's almost impossible to grasp the details of the code in enough fidelity to propose a perfect end solution. Sometimes "little things" end up tripping you up on the way.
So I, programming LabVIEW for over 20 years now, do it similarly. Once you have organised the code sufficiently, a second step can be to improve the code further. By organising a first time, your second refactor may get very close to the "optimal" solution, but it rarely happens in a single step.
But my tip is to make notes of the portions which particularly offend you for later dates. Leave comments on the BD so that next time you see the code, you'll be reminded.
I don't know what others think, but I find an iterative refactoring to be the safest way to get a positive end result unless you have intimate knowledge of the intended inner workings already (i.e. if it's your code).
What he said!
In addition. Participation in the Forums is an excellent means to improve your LabVIEW skills. You'll learn more here by accident than anywhere else by intention. And some creative searching will really pay off.
Creative Searching! I'll give you an example (That I often share with clients.) Tag clouds on User profile pages are not private! Use them! In fact, if you look at my Tag Cloud you will find "Required Reading" and/or "Required_Reading"
NOTE TO SELF: A whole bunch of people are going to wonder where all these new Kudos are coming from.
Yes, I would agree that simply particiating here on the forumns is extremely educational. As you look through posts try to always evaluate any code that gets posted. Not to be criitical to the poster but to see examples of good code as well as bad code. Try to find the common elements of what makes code good and what produces bad code. Make note of some of the tips and tricks which get posted and always be open to doing something a different way.
Re-factoring is a iterative process. It takes time.
In terms of OOP, I highly recommend you familarize yourself with the SOLID principals of OOP design. As you start down the path of OOP try to start in the right direction from the beginning.
Oh, and to add to what Jeff and Mark said, the vast majority of things I learned at the earlier stages of my LabVIEW career was from observing this forum.
I'm still learning from it.
You'll soon learn whose posts are "on your wavelength" so to speak. We're a heterogenous bunch.