As such, many of the non-functional requirements of event logging, such as localizability or a standards-based output format, are explicitly non-goals for most applications of software tracing.
For example, one common use of software tracing, in/out tracing, produces output at the entry point and return of functions or methods so that a developer can visually follow the execution path, often including parameters and return values, in a debugger or text-based log file (this can be seen as a run-time analog of a sequence diagram).
This type of tracing, although useful for developers, can greatly hurt performance of a software product if it cannot be disabled (either at compile-time via conditional compilation, or at run-time via flags).
It can also address the concern of controlling the distribution of sensitive trace information by letting a developer define the human-readable tracing data ("Error %d occurred\n" in the example above) separately from the code so that it is not built into the product (in the code, a specific message is referred to by its message number).
A developer specifies one or more tracing macros that WPP should handle, via a configuration file, special annotations in comments, command line parameters, or some combination of these methods.