Changes between Initial Version and Version 1 of Documentation/T3Q/Quality-Checks/Code-Style

Timestamp:

06/03/10 15:59:45 (15 years ago)

Author:

zeiss

Comment:

Importing pages from "/var/lib/svn/trac/etsicheck2" using ​WikiImport plugin.

Documentation/T3Q/Quality-Checks/Code-Style

@@ +1 @@
+
+=== Code Style ===
+
+==== There Must Be No Labels or Goto Statements ====
+ - '''Symbolic Name in XML Configuration''': checkNoLabelsOrGotoStatements
+ - '''Dependant Tags in XML Configuration''': -
+
+The check makes sure that there are no labels and goto statements in the test code.
+
+==== There Must Be No Nested Alt Statements ====
+ - '''Symbolic Name in XML Configuration''': checkNoNestedAltStatements
+ - '''Dependant Tags in XML Configuration''': maximumAllowedNestingDepth
+
+The check makes sure that there are no alt statements nested within other alt statements or altstep definitions beyond a given depth (specified via the '''maximumAllowedNestingDepth''' configuration tag). The topmost alt or the enclosing altstep definition is considered of depth 0, first level nesting is of depth 1, and so on. The default nesting depth is 0, meaning that no alt statements are allowed within other alt statements or altstep definitions.
+
+'''Example:'''
+
+[[Include(source:trunk/t3q-examples/checkNoNestedAltStatements/checkNoNestedAltStatements.ttcn3, text/x-rst)]]
+
+'''Output'''
+
+The output includes the scope of the alt statement (starting line - end line) and has the following format: 
+
+{{{Alt statement nesting depth (<DEPTH>) exceeds maximum allowed nesting depth (<maximumAllowedNestingDepth>)!}}}
+
+==== There Must Be No Permutation Keyword ====
+ - '''Symbolic Name in XML Configuration''': checkNoPermutationKeyword
+ - '''Dependant Tags in XML Configuration''': -
+
+The check makes sure that there are no permutation keywords in the test code.
+
+==== There Must Be No !AnyType Keyword ====
+ - '''Symbolic Name in XML Configuration''': checkNoAnyTypeKeyword
+ - '''Dependant Tags in XML Configuration''': -
+
+The check makes sure that there are no anytype keywords in the test code.
+
+==== There Must Be No Modified Template of a Modified Template ====
+ - '''Symbolic Name in XML Configuration''': checkNoModifiedTemplateOfModifiedTemplate
+ - '''Dependant Tags in XML Configuration''': -
+
+The check makes sure that there are no modified templates are derived from modified templates. In the example, myTemplate3 is a modified template of degree 2 and myTemplate4 is a modified template of degree 4. Both will be reported by T3Q.
+
+'''Example:'''
+
+[[Include(source:trunk/t3q-examples/checkNoModifiedTemplateOfModifiedTemplate/checkNoModifiedTemplateOfModifiedTemplate.ttcn3, text/x-rst)]]
+
+==== Local Definitions Must Be Declared at the Beginning of Testcases, Functions, Altsteps, and Component Definitions, in a Specified Order ====
+ - '''Symbolic Name in XML Configuration''': checkLocalDefinitionsComeFirst
+ - '''Dependant Tags in XML Configuration''': localDefinitionTypes
+
+This is an evolved version of the check for variables only in the same context (declared before any other statements). In this version, not only variables, but also local constants and timers can be considered (if configured). Additionally, the order of occurrence of these three classes of local definitions can be specified and checked for. With the help of the help of the '''localDefinitionTypes''' configuration tag, which contains a list '''string''' tags, the contents and the order of local definitions can be specified. The default configuration contains four possible types of local definitions: '''!VarInstance''' (variables), '''!ConstDef''' (local constants), '''!TimerInstance''' (local timers), and '''!PortInstance''' (port instances, only within components), configured in this order, meaning that constants are expected to be declared after all variables and before all timers (and ports, in the context of component definitions):
+{{{
+      <localDefinitionTypes>
+        <string>VarInstance</string>
+        <string>ConstDef</string>
+        <string>TimerInstance</string>
+        <string>PortInstance</string>
+      </localDefinitionTypes>
+}}}
+
+
+This order can be changed by moving the configured entries up and down the list. If timers and ports are to be disregarded, for example, then the whole configuration tags shall be omitted, so that the configuration will be:
+
+{{{
+      <localDefinitionTypes>
+        <string>VarInstance</string>
+        <string>ConstDef</string>
+      </localDefinitionTypes>
+}}}
+
+Only the local definition types provided in the default configuration can be used, and only if spelled correctly, meaning that case-sensitivity matters in this context ("constdef" hence will not be recognized).
+
+Note that control part definitions are not analyzed. This will be subject to change, where control part definitions will be analyzed as well.
+
+==== Import Statements Must Be Declared at the Beginning of Modules ====
+ - '''Symbolic Name in XML Configuration''': checkImportsComeFirst
+ - '''Dependant Tags in XML Configuration''': -
+
+Similarly to "Variables Must Be Declared at the Beginning of Testcases, Functions and Altsteps", this check makes sure that all import statements are always at the beginning of any module.
+
+==== There Must Be No Duplicated Identifiers On the Module Level ====
+ - '''Symbolic Name in XML Configuration''': checkNoDuplicatedModuleDefinitionIdentifiers
+ - '''Dependant Tags in XML Configuration''': -
+
+This check will make sure there are no identical identifiers for definitions on the module level among the analyzed modules (regardless of type).
+
+
+==== There Must Be No Unused Definitions On the Module Level ====
+ - '''Symbolic Name in XML Configuration''': checkZeroReferencedModuleDefinitions
+ - '''Dependant Tags in XML Configuration''': zeroReferencedModuleDefinitionsExcludedRegExp
+
+This check will make sure there are no unused definitions on the module level among the analyzed modules, including references through imports. References within import statements however will be disregarded, meaning that if a definition is imported, but never used, it will be considered an unused definition as well. Group definitions are excluded from this check. Additionally, through the '''zeroReferencedModuleDefinitionsExcludedRegExp''' configuration tag, a regular expression can be specified to allow certain modules (based on the module name) to be excluded from this check. The regular expression is empty by default, meaning that all modules are considered by default. 
+
+==== There Must Be No Inline Templates ====
+ - '''Symbolic Name in XML Configuration''': checkNoInlineTemplates
+ - '''Dependant Tags in XML Configuration''': -
+
+This check will make sure there are no inline templates used in the analyzed modules.
+
+==== There Must Be No Over-specific Runs On Clauses ====
+ - '''Symbolic Name in XML Configuration''': checkNoOverSpecificRunsOnClauses
+ - '''Dependant Tags in XML Configuration''': recursionInCheckNoOverSpecificRunsOnClauses
+
+This check will make sure no over-specific '''runs on''' clauses are used. An over-specific runs on clause is when none of the component element definitions (variables, timers, constants, and ports) of the component used in the runs on clause are referenced within the body of the function, test case, or alststep with the runs on clause. If at least one of the component element definitions is referenced within the body of the function, test case, or altstep, then no problem is reported. If the '''recursionInCheckNoOverSpecificRunsOnClauses''' setting is enabled (which it is by default), also the functions and altsteps referenced within the body of the current construct will be inspected. This is due to the fact that often wrapper functions are used that do not make direct use of the component element definitions themselves.
+
+'''Example:'''
+
+[[Include(source:trunk/t3q-examples/checkNoOverSpecificRunsOn/checkNoOverSpecificRunsOn.ttcn3, text/x-rst)]]
+
+==== There Must Be No Unused Imports ====
+ - '''Symbolic Name in XML Configuration''': checkNoUnusedImports
+ - '''Dependant Tags in XML Configuration''': -
+
+This is a rather complex quality check, that seeks to identify unused imports. As a first step it checks whether the imported module exists. If it does not exist, it is either because the imported module is not a part of the analyzed input, or because the name of the imported module has been misspelled. Whatever the case, if the module cannot be resolved, a corresponding message is provided and the check for that particular import statement is finished. If the module can be resolved, depending on the context, the following situations are checked:
+
+ 1. If an '''all''' keyword is used in a non-type-restrictive manner (i.e. not associated to a certain definition type), then it is checked whether there is at least one reference of any module definition from the imported module within the importing module. Whether there are exceptions specified in the import statement makes no difference in this case, because in such a scenario, it is no longer possible to have references pointing back to the imported definition and thus the results of this check remain correct. 
+ 1. If a non-specific type import is used (i.e. an '''all''' keyword is preceded by definition type keyword), then it is checked whether there is at least one reference of any module definition of the given type from the imported module within the importing module. Same conditions apply as in the non-type-restrictive use of the '''all''' keyword. If all groups are to be considered, then only the definitions within groups are considered, those outside groups are not considered.
+ 1. If a specific type import is used (i.e. a definition type keyword, followed by a (list of) identifiers), several checks are performed: 
+  1. Check if the identifier is resolvable. If it is not it means that either the definition is not present within the imported module or the identifier is perhaps misspelled.
+  1. If the identifier is resolvable, it is checked whether the definition is actually within the imported module. It may be the case that the definition has already been imported from another module (see also [[wiki:Documentation/T3Q/Quality-Checks/Code-Style#ThereMustBeNoDuplicatedIdentifiersOntheModuleLevel No Duplicated Identifiers]]), in which case a corresponding message is provided and the actual references for that identifier are not checked any further. It may also be the case that the definition has already been imported from another module, but also does not exist in the module from which it is attempted to be imported again (the definition has been moved perhaps?!), in which case another corresponding message is provided, and no further analysis of the actual references is performed.
+  1. Finally, if the identifier is uniquely and correctly resolvable, is is checked whether there are any references to that imported definition within the importing module. If a specific group is imported, it is checked whether any of the definitions within that group are referenced in the importing module instead.
+
+Note that currently this check is rather computationally expensive and thus '''disabled by default'''. Once suitable optimizations are added, it will be re-enabled by default.
+
+==== There Must Be No Unused Formal Parameters ====
+ - '''Symbolic Name in XML Configuration''': checkNoUnusedFormalParameters
+ - '''Dependant Tags in XML Configuration''': -
+
+This check makes sure there are no unused formal parameters. There are several peculiarities associated with this quality check:
+ * External functions are excluded from this check since their formal parameters can never be used within their TTCN-3 definitions
+ * In the case of modified template definitions, all the formal parameters defined in the modified template (currently matched by name only) are not checked again in the modifying template. Only the additional formal parameters defined in the modifying template are checked in such a case.
+ * Type parametrization is currently left out, since type parametrization is moved to a package in TTCN-3 v4.1.1.
+ * In the case of cyclic call sequences, a corresponding ''INFORMATION'' message will be generated.
+
+==== There Must Be No Unused Local Definitions ====
+ - '''Symbolic Name in XML Configuration''': checkNoUnusedLocalDefinitions
+ - '''Dependant Tags in XML Configuration''': -
+
+This check makes sure there are no unused local definitions. This covers local constants, timers, variables, ports, template variables and local template definitions. Currently component definitions, function definitions, altstep definitions and testcase definitions are analyzed, as well as module control parts.
+
+==== There Must Be No Literals ====
+ - '''Symbolic Name in XML Configuration''': checkNoLiterals
+ - '''Dependant Tags in XML Configuration''': -
+
+This check makes sure there are no literals used, except in module parameters, template definitions, and constant definitions. Note that while in both module-level constants and local constants literals are permitted, in the case of templates, only template definitions at the module level can contain literals. Note also that currently matching symbols, boolean values, verdicts, omit-values, enumerated values, and address-values are not considered ''literals''. This may be a subject to change.
+