Debugging Before Bugs Exist
Good coding practices, such as using white space, including comments, and adhering to naming conventions, help reduce the number of bugs in your code. However, one of the best ways to create a robust application is to look for potential problems before they occur. To make testing and debugging easier later, take the following steps early in the development process:
Creating a Test Environment
Writing Code to Avoid Errors
Setting Asserts
Tracking Event Sequences
Creating a Test Environment
Though the data environment you have set up for the application is important, the system environment that you expect an application to run in is just as important. To ensure portability of your application and to create an appropriate environment for testing and debugging, you need to consider the following items:
Hardware and software.
System paths and file properties.
Directory structure and file locations.
Hardware and Software
For maximum portability, it is recommended that you develop applications on the lowest common platform you expect them to run on. To establish a baseline platform, use the following guidelines:
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 computer that runs your application, you might require a baseline file configuration. To help you define a configuration baseline, consider 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. Avoid this scenario by performing the following tasks:
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.
Writing Code to Avoid Errors
You can help reduce errors by anticipating where they might occur and write code that avoids those errors.
The following table illustrates how to avoid example error conditions.
Error condition |
How to avoid the error |
---|---|
The SKIP command moves the record pointer in a table to the next record. However, if the record pointer has moved past the last record in the table, then calling the SKIP command generates an error. |
Check for end of file:
|
The following line of code displays the Open dialog box so that a user can open a table in a new work area:
The user can choose Cancel in the Open dialog box or type the name of a file that does not exist. The user might also type the name of a file that is not a Visual FoxPro table. |
Make sure that the file exists before the user tries to use it:
If the user types the name of a file that is not a Visual FoxPro table, and error message 15, "Not a table" occurs, you can display a message that prompts the user to open another file, for example, "Please open another file. This file is not a table." |
Setting Asserts
Asserts display message boxes when a logical expression evaluates to False (.F.). You can include asserts in your code to verify assumptions you have about the run-time environment for the code. You can use the ASSERT command to set asserts. For more information, see ASSERT Command.
Tracking Event Sequences
By tracking event sequences in relation to other events, you can determine the most efficient location to add code to events. For more information, see How to: Track Event Sequences.
See Also
Tasks
How to: Use the Automated Test Harness