False Positives

What are False Positives

Globalyzer scans the source code to detect candidate issues based on rules. Given some code, a rule may detect a candidate issue. In one context, that candidate issue may need to be corrected when in another context, the same issue may not need any work and is a false positive.

Let's look at a couple of lines of Java code which creates a date string based on a hard coded date format using SimpleDateFormat: SimpleDateFormat formatter =new SimpleDateFormat("MM/dd/yy"); String dateString = formatter.format(new Date());

Using the default Java rule sets, this code will raise i18n issues. If the dateString variable is user facing, this code is indeed an issue to be fixed (for more information, check your rule set help pages).

However, if the dateString variable is used for internal purposes, such as a in a support log file, it should not be modified and is a false positive.

This section describes different ways to handle false positives.

Modifying Rules

Note: For more detailed information and strategies on filtering rules, please visit False_Positive_Filtering.

Since Rules are what detect or filter out issues, the most common way to handle particular programming styles is to modify the rule set applied to scan a project's code.

Let's look at a string detected by Globalyzer:

SpecialTB.write("New user created");

Globalyzer identifies the string New user created as a candidate embedded string which should be moved out of the code and into a resource bundle. However, let's assume the developer knows that SpecialTB.write() is a method that writes some logging information into a database for potential debugging purposes. The Rule Set needs to be modified based on that knowledge so that this particular line and all other strings passed to this call will be filtered out, i.e. will not be detected as a candidate issue. In this instance, a String Method Filter would be created as shown below:

Any Globalyzer scan using this updated rule set will henceforth filter out the embedded string issue. Workbench instances and the nightly builds for instance would now filter out the issue.

You can also create and try new rules from the Workbench, and push the new rules to the server. To do so, right mouse click on an issue and select the "Add Rule Sets Filters/Detection ..." to show the dialog box.

More Precise Rules

With Globalyzer 5.0, rules are moving to an AST based parsing which provide more powerful rules, starting with Java. Click Globalyzer 5 Java Rules for more information.

Detailed Guide

Visit the [False Positive Filtering] page for a detailed guide on creating false-positive filtering rules.

Globalyzer Comment Tags

When you want to filter out a specific item in the code, one way is to add a Globalyzer comment on the offending line. This is for a specific item and only this one. If more code is written in the same way and Globalyzer should not detect the issue, a Rule Set modification may be better.

Let's look at a simple line of code where Globalyzer detects a candidate issue, here another embedded string:

    String marker = "Marker 15";

By adding the //$NON-NLS-L$ comment at the end of the line, Globalyzer will now ignore the issue:

    String marker = "Marker 15"; //$NON-NLS-L$ 

Since the code is pushed to the source control system, the next time a Workbench user or a script gets the latest code, Globalyzer will ignore the issue.

The default list of Globalyzer Tags is:

• $NON-NLS-L$ : Ignores any issue on the line
• $NON-NLS-[number]$ : Ignores one particular issue on the line. For instance $NON-NLS-2$ ignores the second issue on the line
• GLOBALYZER_TODO : Indicates something to be done in i18n. It overrides/detects the line and sets a TODO status to it.
• GLOBALYZER_IGNORE_NEXT_LINE: Ignores any issue on the line after this comment
• GLOBALYZER_START_IGNORE : Ignores a block of issues until the GLOBALYZER_END_IGNORE tag comment
• GLOBALYZER_END_IGNORE : Stops ignoring a block of issues, working with GLOBALYZER_START_IGNORE

Workbench Status

When using the Workbench, you may want to change the status of some issues locally to your instance of Workbench. This will update the database tracking issues on your system; It does not affect what other users or system detect. This helps organize the issues locally quickly, for instance when externalizing strings with the Workbench.

To change the status of an issue, select it, click the right mouse button, and click on the menu item. In the example below, the issue will be 'Ignored' locally.

Note: You can export a Globalyzer project with the result data. Any user or system can then import that project and it will set the result data status in the local database where the import happened.

Dashboard

The Dashboard shows the latest scan typically run on code in the repository. One can manage issues in the Dashboard. When logged in, a user can act on an issue: comment, assign, and set it to False Positive. The issue will not show up after the next update to the Dashboard.

That status is only in the Dashboard and does not affect issues found in the Workbench.

False positives stick around as the file changes. Below are screenshots of a false positive issue which has persisted for 2 years (as of March 2016). The lines surrounding and including this issue have changed since it was first reported.

The issue above was 2 years old as of March 2016. The line just below it was changed a year after it was first detected.

Additionally, the line itself was changed a few months later. The commit in question can be found here. See lines 268 - 270.

Feedback to Lingoport

For issues you strongly believe are incorrectly detected in the default rule set, feel free to select those lines, press the right mouse button, and select "Report as False Positive". This will send an email with the lines of code and the issues that you feel should not be detected.

This will help Lingoport refine the default rule set for future releases.