General tips

The following list contains suggestions to support your efforts to debug programs, and reduce compilation time, and improve application performance.

• All builds for testing or production should be compiled with the optimization level at which you intend to ship the final product.
• Even if you compile with opt(0) and debug on a regular basis, you should also do some testing at higher optimization levels to ensure that no aliasing rules or ANSI rules have been broken, which would cause the code to be optimized incorrectly.
• You can ensure the cleanest possible optimized compilations, as well as reduce the number of bugs that occur only at high optimization levels, by reviewing every warning issued by the compiler.
  Note: Warnings are often a sign that the compiler is not sure how to interpret the code. If the compiler is not sure how to interpret code at Opt(0), the code could cause an error at higher optimization levels or contribute to longer compilation times.
• The simpler the code is, the more easily the compiler can understand it and the faster it will compile. For more information, see Improving program performance.
• The CHECKOUT (for C) or INFO(for C++) option can be used to look for certain common problems (such as unprototyped functions and uninitialized variables) that can increase both compilation time and execution time.
• Generate production builds each week throughout the project cycle. This makes it easier to determine when problems entered the code base. Waiting until the end of a cycle to generate a build with high optimization can make it more difficult to find errors caused by coding that does not confirm to ANSI aliasing rules.
• Set up a build so that you can customize options for any source file, if necessary. For example, use a makefile for a UNIX System Services-based build with a default rule for compilation. You can then customize targets for source files that require different options. Similarly, use the OPTFILE compiler option for a JCL-based build. A build script can then use a project-level option file for all source files in a module or DLL. You can specify either of the following:
  • Both a project-level option file and additional specific options for a source file
  • A source-specific option file in the option list that follows the options file name
• Set up build scripts so that they can be used for both development and production builds to:
  • Eliminate a common source of errors (because it is necessary to update only one build environment)
  • Make it easier to reproduce and debug problems that occur only in the development build
  • Minimize occurrences of bugs that are reproducible only in the development build