Four suppression modes provided by helix QAC


Today we’re going to talk about perforceHelix QACError suppression function of the tool. Helix QAC provides a variety of different suppression functions that can be used in different scenarios. These functions are divided into:
• suppress errors through annotation
• suppress errors through baseline
• suppress errors through dashboard
• error suppression through #pragma

We will discuss the above four different suppression methods and understand which suppression method is more recommended in which case.

Suppress errors by annotation

Helix QACUsers can use C or C + + annotation methods (such as / * * / or / /) to suppress errors. For example, you can see through the map below that you can use annotation to suppress errors.



The main form of inhibition is prqa s. S stands for suppression, and the error number is basically an ID number unique to each error. In addition, there are other annotation methods to suppress errors in some blocks or a certain source code. For example, as described in the following figure file, EOF can be used to represent the suppression from the code in line 492 to the last line of the file (EOF = end of file), or the suppression function can be turned on or off in the way of + + and — (for example, 0-9999 + + is the function to suppress all outgoing error numbers).



If you need to write some additional description of suppression, you can also write a ‘#’ symbol after the suppression comment to declare.



This method of suppressing errors through annotations is the most common way. The advantage of using this method is that it is very flexible. Users can suppress one or more lines of source code according to their own needs. Of course, the only disadvantage of this method is that the user must write these comments into the source code. Sometimes, users may not want to write QAC comments together with their own project code. If there is such a need, we can look at the description of “suppressing errors through dashboard” below.

Suppress errors through baseline
This method allows users to suppress the errors of the previous version and will not appear in the analysis results of the next version. This function basically allows users to select a version or time point to suppress previous errors and report only subsequent errors. This suppression method is usually applicable when users are analyzing legacy

Suppress errors through dashboard
The advantage of dashboard is that in addition to not seeing any QAC suppression comments in the code, you can also use this usage to ensure that the suppression settings used by all clients are the same – because all errors are managed uniformly through dashboard. Users can set the account permission to log in to the dashboard to ensure that only those with permission can suppress it, and other users can only see the results, or download the suppression file to directly apply this setting for analysis.

Suppress errors through #pragma
This suppression method is the predecessor of annotation suppression. This feature is still available, but it may be removed in a future version. If possible, users will use annotation suppression directly instead of this #pragma method. This #pragma error suppression method is through the use of “#pragma”



If you use annotation suppression to achieve the same effect, it will basically be as shown in the map below.



Finally, this #pragma suppression method can be applied to macro extension. For example:
       #pragma PRQA_MACRO_MESSAGES_OFF “mymacro”
The above example will suppress all errors on any ‘mymacro’ extension
      #pragma PRQA_MACRO_MESSAGES_OFF “mymacro” 3344
The above example will only suppress the error ID 3344 on any extension of “mymacro”
Today, we discussed four suppression methods that helix QAC can provide. We can learn from the above description how to use these error suppression methods and suggestions, in which case it is better to apply which method. I hope this article can let you further understand the annotation method of helix QAC.

 “Original content, please indicate the source for reprint”

Recommended Today

Swiftui learning-1 understanding of MVVM

MVVM Originally, we have been developing with Objective-C, and the application itself is based on MVC to build the code structure. Recently, we learned that swiftui must comply with MVVM to work, so we began to understand this concept deeply. Mainly through the open class of Stanford University, summarize the important knowledge points. Link below: […]