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.
- 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 Insight'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.
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.
- Tuning C/C++ analysis
- Tuning Java analysis
- Tuning Java analysis in Eclipse
- Tuning Java analysis in IntelliJ IDEA
- Java knowledge base reference
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, Insight 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
Note: It's not possible to import and export configuration files in Visual Studio.
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.xml)
- one metric threshold file (.mconf)
- one usage rules file (.uconf)
- multiple knowledge base files (.kb or .jkb)
- multiple override files (.h) (C/C++ only)
If a project already contains a .mconf, .uconf, or .pconf.xml file, any additional imports of these file types will automatically overwrite any 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. The relevant kwcheck commands are: