Because it is so easy to create working prototypes in a visual programming language, good programming practices often are neglected when complete tests are generated. This neglect leads to additional debugging time and higher maintenance costs.
But you can avoid common pitfalls by implementing programming practices used in text-based languages in a graphical programming environment. These practices make visual programming more efficient through the entire life cycle—from design to maintenance.
Good Visual Programming Practices
The first time you start up a visual programming language, you’re amazed by how easy it is to use. You start to experiment and connect a couple of objects, and in just minutes you’ve created a test module. Program for a few more hours, and the test is nearly done.
Six months later, you need to make some minor modifications to the program. As you scan the screens of lines and objects, you’re not sure where to start. Hours later you’ve made your changes but are bleary-eyed from looking at each object and connection. You wonder why a language so easy to program in is so difficult to modify. Welcome to the world of visual programming.
It’s easy to forget that visual programming is still programming. Just as with conventional programming, your programs are faster to write, easier to debug, and
simpler to maintain when you use good programming practices.
Design, Design, Design
Situation: Your program looks like Kansas—big and mostly flat.
For both visual and conventional programs, the most important practice is to design them. Even though it is very easy to start connecting objects and generate a working prototype, do not create a test until you have a plan (Figure 1).
A graphical program looks similar to a flow chart, but you still need to design the tasks and the structure. First, choose a design approach. Generally, a top-down approach works better with visual programming. Then you map out the different modules and their functions.
Although a structured program may take more time to design, there are advantages:
The overall code generally is more efficient because overhead is minimized.
Testing and debugging times are minimized. Finding and correcting errors are faster.
Maintenance is simplified. Adding new features is easier and other programmers can readily modify your code.
Some programmers say they keep the structure flat because a hierarchical structure hides program functionality. But many visual languages allow you to easily track multiple levels of modules and functions.
For example, a language like HP VEE has a window that shows the structure of the program via an MS Windows Explorer-type interface. Other languages, like LabVIEW, show a tree-like structure. This functionality allows you to view the structure of the entire program at a glance.
Program Readability
Situation: Your program has hundreds of objects that all look alike.
Another basic programming practice is to make your program as easy as possible to read (Figure 2). Some techniques are:
Make an object’s appearance meaningful. Use meaningful names. Change the default name of an object to one that describes the exact use of the object. For example, on a formula object, change the name to the equation itself, such as “pi*r**2” or change an iteration object’s name to “Loop from 10-100.”
Not only does this practice make your program easier to read, but it also helps you to find an object faster. Many graphical programming languages have some kind of find feature that lets you search through the program for an object’s title.
Use a naming convention. Some programmers begin all function names with F_ and all global variable names with G_. You can create your own style guide of conventions.
Increase object name readability. Make sure objects are big enough so that you can read the names easily. Use a font large enough so you are comfortable when scanning your program. Text written in a sans serif font is easier to read on the screen. Use a nonproportional font if you want text to line up, but proportional fonts generally are read faster.
Use visual cues. Some languages let you assign graphical images to objects. Simple graphics will work here. For example, you can use a stop sign for an exit function object or a stopwatch for a timer.
Keep your objects large enough to be readable. It’s tempting to resize your objects as small as possible to fit more on a screen, but you will spend more time trying to locate the object you need.
Lay out objects in rows and columns. It may feel like interior decorating until you realize how much more understandable your programs are when a minimum of lines cross, and it’s clear where inputs come from and outputs go. Avoid “spaghetti code.” If you have a confusing array of lines crossing each other, try passing variables as globals instead of via lines, increasing the spacing between objects, or rearranging the objects to minimize the confusion.
Some languages have alignment and spacing tools to help improve your program layout. Other languages also have tools to simplify the layout of lines to only orthogonal directions. Be careful not to place objects on top of other objects. Allow enough room so that no details of your program are hidden.
Use color conventions. Some programmers use color to distinguish different classes of objects. For example, make all function call objects green and all initialization objects yellow. This method is very time-consuming, and it may be difficult to maintain a color scheme. But it does greatly improve the readability of the program.
Add Comments
Although visual languages generally don’t have comments per se, there almost always is some equivalent. You can place comments in the body of the program.
These comments may be called labels or notepads, depending on the language. Generally, you also can attach comments to describe the specifications of the objects. Some good information to include in any program documentation is:
Purpose of the program.
User input or interaction required.
Explanation of the general organization and theory behind the program.
Output expected.
If you are not using a history management system, supply your name and the dates of creation and modification within the program. Good information to specify for objects includes:
Purpose or function of the object.
Input expected, including data type and description.
Output expected, including data type and description.
Take Advantage of Visual Programming
Situation: Your visual program looks like C code blocks connected together.
Use high-level objects and constructs. Visual languages have strengths in different areas than text languages. For example, you don’t build displays from line primitives because you have the advantage of pre-built functionality.
Create complex math statements in only one object. Perform math operations on an entire array with one step—no iterating through each of the elements. Other constructs could include pre-built dialog boxes, counters, accumulators, and timers or high-level instrument drivers. Once you know the particular constructs in your graphical language, you will write more compact, faster executing code.
Many languages include execution profilers that show how much time functions take to execute. When you know the high-level constructs and how they increase the execution speed of your program, you can use them to optimize the execution times of the functions identified by the profiler.
Learn Propagation Rules
Propagation rules are the backbone of your program; they specify the order of execution of objects. If you don’t know the rules, your program will run less efficiently, and it will be harder to debug.
Often programmers try to guess the execution order of a graphical program. If it runs as expected, the programmers stop working. But because visual programs often have elements that execute in some undefined, parallel order, you must know the rules.
A program that runs fine today may not work exactly the same way tomorrow. Conversely, because many visual programming languages use data-flow constraints, programmers often spend unneeded time manually constraining the order of objects when the availability of data on the lines automatically does that.
Do not create a visual program like a text-based program. For example, do not connect the end of a loop in visual programs to the beginning of the loop. The propagation rules know when the loop is done. Also beware of feedback; that is, sending data to objects that have already executed.
In text-based programs, it’s just a GOTO. In visual programs, many times nothing will happen. The objects have already executed. Sending new data in will not cause an object to execute again. If you truly need feedback in your program, use it within a loop so that the object will execute again with the new data.
Manage Your Memory
Although a C programmer wouldn’t think of writing a program without using “malloc” to allocate memory or “free” to free up memory, you’ll find that memory management for visual programs is not so straightforward. To get the best memory usage from your program, find out the specifics of how your language allocates memory. Because visual programs may keep variable data in memory until the program finishes executing, you may get out-of-memory messages or, at least, slow execution speeds.
Some common ways to avoid memory problems in visual programs include:
Divide large programs into smaller functional units.
Use global variables. Delete them when they no longer are needed.
Import functions when they are needed and delete them after they are used.
Summary
Although the implementations of good programming concepts are different between text-based and visual programs, the benefits are the same: easier maintenance.
About the Author
Vicki Pompea, who has worked for Hewlett-Packard for 12 years, is a learning products engineer at the company’s Measurement Systems Division. She graduated with a B.S. degree in computer engineering from San Jose State University in 1985. Hewlett-Packard, Measurement Systems Division, 815 14th St. S.W., Loveland, CO 80537, (917) 350-4862.
Copyright 1998 Nelson Publishing Inc.
March 1998
|
|