How to go from simple working code to professional code

[PhilBot]

I agree with most of the comments here, but I'm very surprized that noone has mentioned SubVIs (OK, sorry, a small mention .

If you have a large program that is starting to fill the screen, the BEST way that I know to simplify it is to start thinking of which parts could be best moved into a SubVI.

I beleive that moving from one large program into a programming structure that uses smaller, smarter components is the KEY step which differentiates a "rookie" programmer from a "professional" programmer.

The main reason is that creating good SubVis, or Subroutines, or Libraries requires a certain abount of forethought and planning. Developing your own set of "rules" for this is a real growth experience.

But... for somone just getting started, there are probably two easy ways to know when to create a SubVI:

1) Do you find yourself cutting and pasting code? If so, then STOP! and create a SubVI to embody the function that you are duplicating. Figure out what is common in every copy you were creating and what was changing. Put the common parts in the SubVI, and make the changing parts inputs to the SubVI. LabVIEW makes it very easy to create SubVIs. Just rubber-band ther parts that don't change and select... Edit/Create SubVI. Once you have one, personalize it with your own custom Icon and don't forget to add a description.

2) When you find yourself making one section of your program more and more complicated, to the point where you are moving things around to make space for it..... STOP!, and put that functionality into a SubVI. This way the overall program can stay simple, and the complexity can be hidden in the SubVi .. Then when you need to change the complax part, just drill into the SubVI.

Phil.

[Boydean]

I have little experience with Labview but this subject interests me, and a lot of this advice can be applied to other areas of software development.

Echo what is being said above. Simplify. If something is too complex to explain in plain english then you need to break it down more (more SubVis).

Your code (or blocks) should be explicit as possible. Variables should state what its used for in plain english. Remember that code is read more then it is written – so take the time to actually type "map" and not something like "mp". You ain't special for naming something other people won't understand.

Functions and methods (SubVis) should state what they do in plain english. Use verbs and nouns if the function does something. Example "set_motor_speed" vs "motor_speed".

Comments. Abusive commenting is abusive to the reader. No one wants to read an entire paragraph of comments in the middle of some code. Changing focus from reading coding to interrupting comments with code is annoying. If your code is explicit enough then comments should only be used to explain why you are doing something.

Bad:

// Set motor speed to 0.5.
set_motor_speed(0.5);

Good:

// Anything greater then 0.5 will destroy our arm. Monkeys are awesome. – @brandondean Nov 17
set_motor_speed(0.5);

EDIT: Global variables are bad. Don't use them. Although, if I recall correctly with Labview this is unavoidable...I think.

[Greg McKaskle]

Originally Posted by Boydean

Global variables are bad. Don't use them. Although, if I recall correctly with Labview this is unavoidable...I think.

I agree with everything in the post, except for the global part. I'm not going to claim globals are the best overall mechanism for sharing data, but they have their place, they are simple to understand, and that makes them a reasonable place to start out. This is why they are used in the LabVIEW template code.

Just to be clear, LV has many other data sharing mechanisms, and it is not necessary to use globals. If you feel that you are ready for it, read up on queues, notifiers, rendezvous, occurrences, or perhaps the RT FIFO. Finally, the sharing I personally use the most often is the functional global -- a custom subvi critical section wrapper with just the read and write operations I need. You may be tempted to use events because you have heard about them elsewhere, but since they are primarily for UI operations, they are not appropriate for RT, and the notifier or FIFO is the equivalent choice.

Greg McKaskle

[Ether]

Originally Posted by Boydean

EDIT: Global variables are bad. Don't use them.

I realize that statement was made in the context of FRC and LabVIEW, but in case a reader might think it is a universal principle it should be noted that there are contexts in which it is not true.

Global variables are often indispensable for software for high-volume automotive applications with penny-pinching hardware. If managed meticulously, they can be essential for a successful product.