![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
C/C++ Code Rule Checker In team program development, code rules are often used to ensure that programs being developed conform with a `standard' programming style. This makes the collectively developed program more readable and less error-prone. As a result, the cost of development and maintenance are reduced.
The code rule checker operates on the Sienna intermediate representation of the units, so they must already be compiled.
Sienna is a persistent intermediate representation of the C++ source. It is the basis for code rule checking and navigation.
Sienna is generated by default unless the -nosienna switch is passed to the compiler by the build key. It is stored in files in the .Rational/Compilation/cna subdirectory of the view. Sienna generation is the default, and to turn it off it is necessary to create a new build key with -nosienna.
A number of types of warnings can occur if sienna generation is enabled for C/C++. These are described in detail in Sienna Warning Messages.
The following topics are covered in this chapter:
- Navigation
- Code Rule Checker Displays
- Code Rule Syntax
- Predefined Code Rules
- Interface to the Code Rule Checker
- Sienna Warning Messages
NavigationFor navigation, the fact that Sienna is used is mostly invisible to the user, except that it is better at resolving ambiguities. If there is a reference to an identifier, Navigate > Visit on the identifier will find the correct definition, even if there are multiple definitions of the same name. If the Sienna-based navigation fails, the editor falls back on the current tags-based navigation.
Code Rule Checker DisplaysWhen the code rule checker executes, it examines the file(s) for any code rule violations. If a file violates any of the code rules, the violation(s) are highlighted in the source file. Choose Help > Explain in the editor window and click on the highlighted area for more details on the violations.
If multiple files have violations, a summary window listing all the files with violation is displayed. Use the Visit button on a file name to display the editor window of the corresponding file with all its violations highlighted.
Code Rule SyntaxIn Apex, a code rule is represented as a triplet: a name, a switch attribute, and actual code body for checking the rule.
A rule name should be a string with alphanumeric characters and underscores (`_').
The switch attribute of a code rule can be one of the three states:
Uni_State rule has no associated value (e.g., Use_Clause_In_Use)
Bi_State rule can be associated with boolean values
Nary_State rule can be associated with integer values (e.g., Maximum_Loop_Nests)
The Rational Apex code rule checker uses the code rules in the file Policy/Code_Rules.sw in the source view to determine which code rules to check, and the severity level each code rule will be treated on. Each source view can have its own code rule set, so this file can be different from one view to another.
Predefined Code RulesIn Rational Apex, there are predefined code rules for the code rule checker. The values of the switch attributes and severity levels of these rules can be changed by the user. The code rule checker employs the settings and does the checking accordingly.
The format of the Policy/Code_Rules.sw is lines of the form:
Value is "On" or "Off", or a number, as appropriate.
Severity is "Error", "Warning", or "Informational". [Default: Warning]
Comments are introduced by "#" and continue to the end of the line.
The following is a list of the current rule names and what they check for:
- Ambiguous_Operator_In_If_Condition
Checks for "=", "&", "|", or "^" as the condition of an "if".
- Parentheses_Recommended_For_Logical_Operators
Checks for reliance on precedence for combinations of "&&" and "||".
- No_Break_In_Switch_Case
Checks for cases that don't end in "break", "return", "goto", or "continue".
- No_Default_Case_In_Switch_Statement
Checks for switch statements with no default label.
- Private_Or_Protected_In_Struct
Checks for "struct"s or "union"s with "private" or "protected" members.
- Member_Access_Control_Order
Checks that classes have members in the order: "public", "protected", "private".
- Unshared_Base_Class
Checks for base classes that should be declared virtual to force sharing of data members.
- Nonvirtual_Destructor_Defined_In_Base_Class
Checks for classes that are used as a base class and have a non-virtual constructor.
- Inheritance_In_Use
Checks for use of inheritance.
- Multiple_Inheritance_In_Use
Checks for use of multiple inheritance.
- Maximum_Inheritance_Depth
Checks for depth of derivation tree that is more than specified maximum.
- Public_Data_Member
Checks for classes with public data members.
- Nonvirtual_Member_Overriding_Virtual
Checks for a virtual member function being overridden by a non-virtual.
- Pure_Virtual_Not_Overridden
Checks for a derived class that doesn't override every pure virtual member function of its base classes.
- Missing_Constructor
Checks for classes that don't have a constructor.
- Virtual_Member_And_Nonvirtual_Destructor
Checks for classes with a virtual member and a non-virtual destructor.
- No_Destructor_For_Matching_Constructor
Checks for classes that have a constructor and no destructor.
- No_Matching_Delete_For_New
Checks for classes that define "operator new" but not "operator delete".
- No_Matching_New_For_Delete
Checks for classes that define "operator delete" but not "operator new".
- No_Destructor_For_Constructor_With_New
Checks for a constructor that uses "new" (immediately within its body) but doesn't have a corresponding destructor.
- Overloading_Global_New_Operator
Checks for redefining the global "operator new".
- New_And_Delete_Should_Both_Be_Overloaded
Checks for redefining the global "operator new" without redefining global "operator delete" also.
Interface to the Code Rule CheckerYou can display the defined code rules or check files against the defined code rules using either the command line interface or the Apex GUI.
Command-Line Interface
To check files against the defined code rules use the check_rules command. It is discussed in detail in the Command Reference.
GUI Interface
From the Apex GUI, the commands Compile > Check Rules and Compile > Show > Code Rules provide access to the code rule checker. Compile > Show > Code Rules simply displays the code rules in effect for the selected object(s). Compile > Check Rules checks the current selection against the predefined code rules. When this command is selected, the Check Code Rules dialog box is displayed.
Sienna Warning MessagesEach of these sienna related warning messages can be suppressed by passing the flag -Wwarning_type to the C/C++ compiler where warning_type is heapmaper, siennaer, siennack, siennard, siennawr, siennanr, or siennanc.
These first three types of warnings don't cause sienna generation to be suppressed (except heapmaper version mismatch). Generally, the generated sienna is nearly or completely intact. Navigation and code rule checking should still work. There may be one or more missing links that prevent navigation from one or more source positions.
heapmaper
file.cc, line 1: Warning: Sienna heap map (<path to heapmap
>) <message
>.The sienna heapmap database is not consistent with the current compilation environment. Most of these warnings have no consequence except to fix the heapmap database and regenerate some sienna files that may have been reused otherwise. The message gives further details about the specific problem and is self explanatory. A common one is: "file has date older than heapmap entry. Resetting" which can be caused by compiling in a shared area in different environments which share the same include paths but different include files.
siennaer
file.cc, line 1: Warning: Sienna - Internal Error <message
><message> may contain a reference to source that is not part of your application. It also identifies the particular problem. For example:
- Table overflow...: Insuffient space in internal tables; to allow for complete sienna generation, break code into smaller components.
- Bad link...: Reference to unknown external link.
- Internal X not found...: Reference to unknown identifier; causes include incorrect owner of sienna files, incorrect export declaration of identifier, sienna heap inconsistency.
siennack
file.cc, line 1: Warning: Sienna incomplete due to internal error (XXXX-NNNN
); debugging may be impaired.The next four types of warnings prevent sienna generation for the compilation. If any of these occur, navigation from the compilation will not work.
siennard
file.cc, line 1: Warning:Sienna heap inconsistency due to internal error. Sienna generation suppressed.The compiler attempted to reuse a sienna heap it should not have. The source file has different syntax (after preprocessing) between compilations and the difference was not automatically detected as it should have been.
By the time the inconsistency is discovered, it is too late to recover and sienna for the compilation is not generated. The source position referenced in the message should point near a macro expansion.
The last three types of errors mean the compiler is not able to read/write the specified file. There could be file permission problems, non-existent directories, or bogus .Rational_Location links someplace in the specified path.
siennawr
file.cc, line 1: Warning: Unable to create sienna in <path>. Sienna generation suppressed.siennanr
file.cc, line 1: Warning: Unable to read sienna heap <path>. Sienna generation suppressed.siennanc
file.cc, line 1: Warning: Unable to create sienna heap <path>. Sienna generation suppressed.
Rational Software Corporation http://www.rational.com support@rational.com techpubs@rational.com Copyright © 1993-2002, Rational Software Corporation. All rights reserved. |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |