In this topic:
When to enable or disable checkers When to tune your analysis When to write your own checkers When to set metric threshold and usage rule violations Importing and exporting configuration files

Customizing your desktop analysis

The customization process begins with an inconvenience, typically in the form of a false positive or "excess noise" from a checker that's not really applicable to your code base.

Traceback information is a key diagnostic tool in determining the validity of your results and gathering information you need to fix detected issues.

Note:

You can only customize your analysis if you have permission to change your local configuration.
The Visual Studio plug-in only allows you to enable or disable checkers.

When to enable or disable checkers

You can enable or disable Klocwork's default checkers so you see only the issue types of interest to you. For example, if there's a reported issue type that your team consistently cites as "Ignore" or "Not a problem" (and their assessment is valid), you can turn the checker off, so it won't be detected in a future analysis.

If there's an issue type that's not being detected but you think it should be, you can check the default checkers in the Configuration Editor to see if it's missing because it was disabled. If it exists in the list, just enable it and run the analysis again.

Any time developers enable or disable issues, a user profile (userprofile.pconf.xml) is automatically created in your project. This user profile can be exported and imported for sharing among team members.

For kwcheck, run the Configuration Editor or use the commands kwcheck enable and kwcheck disable.

When to tune your analysis

If certain occurrences of a particular issue type are false positives, but the issue type itself is still a useful one to detect, you can tune your analysis to remove these occurrences of false positives.

For example, if you notice that there's a validation in the traceback or near it, but the issue is still being detected, tune that checker so that it detects the validation.

Knowledge base files are used for tuning purposes.

When to write your own checkers

If there's an issue type that is not included in the default checker list, you can create your own.

When to set metric threshold and usage rule violations

You may want to report functions or class-methods that exceed a specified threshold for complexity or that fail to meet a specified percentage of comments. These are just a few of the many metric thresholds you can establish for a desktop or integration project.

By adding usage rules relevant to your specific software system and your organization's policies and quality objectives, Klocwork can become a valuable tool in helping maintain the integrity of your software system's architectural design, coding standards and security. For example, you can create rules that flag the use of undesired entity types.

Importing and exporting configuration files

You can export configuration files from your project or workspace to distribute among team members, who can then import them. Exporting a file from your workspace does not remove the file from your workspace.

If you are connected to a server project, your local configuration settings take precedence over the integration project's configuration settings.

A project can contain:

one user profile (.pconf)
one metric threshold file (.mconf)
one taxonomy file (.tconf)
multiple knowledge base files (.kb or .jkb)
multiple override files (.h) (C/C++ only)

If a project contains a .mconf, .pconf, or .tconf file, any additional imports to these files types will automatically overwrite existing files.

Note: All configuration files used in Klocwork analysis must be UTF-8 encoded if they contain multibyte characters (for example, Japanese). Convert the files before importing them into your project. See kwconv.

If you use kwgcheck on the command line, you must use kwcheck to import and export configuration files. See kwcheck