Share via


Debugging Before Bugs Exist

Studies have shown that good coding practices (using white space, including comments, adhering to naming conventions, and so on) automatically tend to reduce the number of bugs in your code. In addition, there are some steps you can take early in the development process to make testing and debugging easier later on, including: creating a test environment, setting asserts, and seeing event sequences.

Creating a Test Environment

The system environment that you expect an application to run in is as important as the data environment you have set up for the application itself. To ensure portability and to create an appropriate context for testing and debugging, you need to consider hardware and software, system paths and file properties, and directory structure and file locations.

Hardware and Software

For maximum portability, you should develop applications on the lowest common platform you expect them to run on. To establish a baseline platform:

  • Develop your applications using the lowest common video mode.
  • Determine base requirements for RAM and media storage space, including any necessary drivers or concurrently running software.
  • Consider special memory, file, and record-locking scenarios for network versus stand-alone versions of applications.

System Paths and File Properties

To ensure all necessary program files are readily accessible on each machine that will run your application, you might also require a baseline file configuration. To help you define a configuration baseline, answer the following questions:

  • Does your application require common system paths?
  • Have you set appropriate file access properties?
  • Are network permissions set correctly for each user?

Directory Structure and File Locations

If your source code references absolute paths or file names, those exact paths and files must exist when your application is installed on any other computer. To avoid this scenario, you can:

  • Use Visual FoxPro configuration files. For additional information on using configuration files, see Customizing the Visual FoxPro Environment.
  • Create a separate directory or directory structure to keep source files apart from the generated application files. This way, you can test the references of the completed application and know exactly which files to distribute.
  • Use relative paths.

Setting Asserts

You can include asserts in your code to verify assumptions you have about the run-time environment for the code.

To set an assert

  • Use the ASSERT command to identify assumptions in your program.

    When the condition stipulated in the ASSERT command evaluates to false (.F.), an assert message box is displayed and echoed to the Debug Output window.

For example, you could be writing a function that expects a non-zero parameter value. The following line of code in the function alerts you if the value of the parameter is 0:

ASSERT nParm != 0 MESSAGE "Received a parameter of 0"

You can specify whether assert messages are displayed with the SET ASSERTS command. By default, assert messages are not displayed.

Seeing Event Sequences

When you see events occur in relation to other events, you can determine the most efficient place to include your code.

To track events

The Event Tracking Dialog Box allows you to select the events that you want to see.

Note   In this example, the MouseMove and Paint events have been removed from the Events to track list because these events occur so frequently that they make it more difficult to see the sequences of the other events.

When event tracking is enabled, every time a system event in the Events to track list occurs, the name of the event is displayed in the Debug Output window or written to a file. If you choose to have the events displayed in the Debug Output window, you can still save them to a file as described in Output Display.

Note   If the Debug Output window is not open, events will not be listed, even if the Debugger Output Window box is set.

See Also

Setting Asserts | Isolating Problems | Testing and Debugging Applications | Debugger | Seeing Stored Values | Using the Automated Test Harness