| |
|
|
|
|
|
Standards-Conformance
and Compatibility Rule LibrariesThis section lists all currently supported rules for checking the conformance of Ada software to quality standards and guidelines. These checks are grouped into four separate rule libraries:
- Ada 95 rules
- Software Productivity Consortium's guidelines for Ada quality and style
- Rational target-compatibility rules
- Little Tree Consulting's software-quality guidelines
Ada 95 Rules
The following rules check whether a program written in Ada 83 is compatible with the semantics of Ada 95. Some rules are considered errors and their violation will definitely result in an incompatibility. Other rules are considered warnings and may or may not result in an incompatibility with Ada 95. They are included here so that these potential problems can be found and additional analysis performed.
- Ada95 01: Use of the new Ada 95 key words as identifiers —— abstract, aliased, protected, requeue, tagged, and until.
- Ada95 02: Use of the following as identifiers: Wide_Character and Wide_String.
- Ada95 03: Use of the following as identifiers when package System is used: Max_Base_Digits, Max_Binary_Modulus, Max_Nonbinary_Modulus, Null_Address, Bit_Order, Default_Bit_Order, Any_Priority, Interrupt_Priority, High_Order_First, Low_Order_First.
- Ada95 04: Use of library-level compilation units named Ada or Interfaces.
- Ada95 05: Declaration of library-level package specifications that do not contain subprograms, tasks, deferred constants, or incomplete types must not have a body.
- Ada95 06: Use of the attribute T'Base on composite types.
- Ada95 07: Use of the exception Numeric_Error in raise statements or exception handlers.
- Ada95 08: Use of representation clauses that do not immediately follow the declaration of the type they represent.
- Ada95 09: Use of the following attributes —— 'MANTISSA, 'EMAX, 'LARGE, 'SMALL, 'EPSILON, 'SAFE_EMAX, 'SAFE_LARGE, 'SAFE_SMALL.
- Ada95 10: Use of the following as identifiers when package Text_Io is used —— Set_Error, Standard_Error, Current_Error, Flush, Is_Open, Look_Ahead, Get_Immediate, Modular_Io, Decimal_Io, File_Access.
- Ada95 11: Use of derived types whose parent type is declared in the same package.
- Ada95 12: Use of, or reference to, the Standard.Character type in contexts where the new literals (now 256 instead of 128) would render the program illegal or change the program's behavior. These contexts include use as an array index, use as a discrete range in a loop, reference to Character'Last, or use in a case-statement expression.
- Ada95 13: Use of character and string literals in contexts where the subtype would be ambiguous (with Wide_Character and Wide_String). These contexts include use in relational expressions, discrete ranges, and some type qualifications.
- Ada95 14: Use of, or reference to, the Text_Io.File_Mode type in contexts where the new enumeration literal (Append_File) would render the program illegal or change the program's behavior. These contexts include use as an array index, use as a discrete range in a loop, reference to File_Mode'Last, or use in a case statement expression.
- Ada95 15: Use of functions that return task types or types containing task types.
- Ada95 16: Use of pragmas defined by the Ada 83 language that are not defined by the Ada 95 language standard.
- Ada95 17: Use of `size attributes whose attributed entity has a static size (in bits) that is not an even multiple of the byte size of the target machine.
Default Ada 95 Enforcement
Software Productivity Consortium's Guidelines
The following rules check some of the programming guidelines defined by the Software Productivity Consortium in Ada Quality and Style, Version 01.00.10, October 1995. Many of the guidelines defined in that document are too general to be checked automatically. Those that are specific enough are listed below with a reference to the paragraph in which they are defined. Some rules have been adapted slightly to make them more specific and thus more amenable to automatic checking. All rules are stated in the negative.
Note: Complete descriptions of all SPC rules can be found on the net at http://www.adaic.org/AdaIC/docs/style-guide/95style/html/contents.html
- SPC 3.1.4.f: Use of abbreviations not on an approved list. Identifier segments that are misspelled and not in the allowed abbreviation list are considered violations of this rule. Allowed abbreviations are stored in the allowed_name_abbreviations file located in the standards_conformance subdirectory of the current configuration.
- SPC 3.2.6.j: Use of numeric literals in nondeclarative parts of the program.
- SPC 4.1.1.b: Use of library-level subprograms that are not main programs.
- SPC 4.1.1.c: Use of child units is encouraged over subunits.
- SPC 4.1.1.g: Use of private child units is encouraged over nested packages.
- SPC 4.1.4.b: Functions with side effects (that is, that update variables outside their scope).
- SPC 4.1.8.a: Variables declared in the visible part of a package.
- SPC 4.2.4.a: Tasks declared in the visible part of a package.
- SPC 4.3.1.c: Declaration of exceptions in a nonvisible part of the program.
- SPC 4.3.1.j: Raising of predefined exceptions.
- SPC 5.1.1.a: Nested loops that are not named.
- SPC 5.1.1.b: Loops containing exit statements that are not named.
- SPC 5.1.2.a: Nested blocks that are not named.
- SPC 5.1.3.a: Exit statements without an explicitly named loop.
- SPC 5.2.2.a: Missing named-parameter association in subprogram and entry calls.
- SPC 5.2.2.b: Missing named association in generic instantiations.
- SPC 5.2.3.b: Default parameters that do not appear at the end of the parameter list.
- SPC 5.2.4.a: Missing mode indication on procedure and entry parameters.
- SPC 5.2.4.b: Use of the most restrictive mode possible for parameters. A parameter that is only read should be mode in.
- SPC 5.3.1.b: Subtype declarations with no range constraint.
- SPC 5.3.1.d: Derived type declarations with no range constraint.
- SPC 5.3.2.a: Use of anonymous types.
- SPC 5.4.5.h: Absence of length clause to specify total allocation size for access types.
- SPC 5.4.5.i: Use of allocators without an exception handler for Storage_Error.
- SPC 5.4.8.a: Use of modular types when using bit-wise Boolean operators is preferred for efficiency reasons.
- SPC 5.5.3.a: Fully parenthesized expressions.
- SPC 5.5.4.a: Use of the not operator.
- SPC 5.5.5.a: Use of the or and and operators instead of short-circuit forms.
- SPC 5.5.6.a: Use of the "=", "/=", "<", and ">" operators with real operands instead of "<=" and ">=".
- SPC 5.6.3.a: Use of an others choice in a case statement.
- SPC 5.6.3.b: Use of an enumeration literal range as a choice in a case statement.
- SPC 5.6.4.d: Use of exit statements in while and for loops.
- SPC 5.6.4.e: Presence of more than one exit point from a loop.
- SPC 5.6.5.b: Use of bare exit statements directly inside an if statement instead of exit when.
- SPC 5.6.7.a: Use of goto statements.
- SPC 5.6.8.a: Functions with more than one return statement in the body; procedures containing any return statements.
- SPC 5.6.10.c: Missing named association in record aggregates.
- SPC 5.7.1.b: Use of any use clause not on an approved list. This list is stored in the file named allowed_use_clauses in the standards_conformance directory of the current configuration.
- SPC 5.7.2.f: Use of unapproved renames.The list of approved renames is stored in the approved_renames file in the standards_conformance subdirectory of the current configuration.
- SPC 5.8.1.d: Explicit raising of exceptions that are then caught in the local scope (that is, used as a goto).
- SPC 5.8.2.a: Use of when others in an exception handler.
- SPC 5.9.1.a: Use of Unchecked_Conversion.
- SPC 5.9.2.a: Use of Unchecked_Deallocation.
- SPC 5.9.2.b: Missing Deallocation of local access types.
- SPC 5.9.3.a: Use of `UNCHECKED_ACCESS attribute.
- SPC 5.9.4.a: Use of address clauses.
- SPC 5.9.5.a: Use of pragma Suppress.
- SPC 5.9.6.f: Use of functions declared in the same context to initialize object declarations (elaboration).
- SPC 5.9.9.a: Protected types should not invoke blocking operations in their execution closure. Blocking operations include select statements, accept statements, entry calls, delay statements, abort statements, external calls to protected subprograms, or external requeues.
- SPC 6.1.5.a: Use of dynamically allocated tasks.
- SPC 6.1.7.b: Use of delay statements instead of delay until.
- SPC 6.2.3.a: Use of the attributes 'CALLABLE, 'TERMINATED, and 'COUNT.
- SPC 6.2.4.c: References to non-local variables in select guards should not be made since references will not be synchronized.
- SPC 6.2.5.a: Use of conditional entry calls.
- SPC 6.2.5.b: Use of selective waits with else parts.
- SPC 6.3.1.a: Absence of an exception handler in the main loop of a task.
- SPC 6.3.2.d: Absence of a terminate alternative in select statements without an else part or a delay.
- SPC 6.3.3.a: Use of the abort statement.
- SPC 6.3.4.a: Existence of a when others exception handler at the end of a task body.
- SPC 7.1.4.a: Use of parameters in main programs.
- SPC 7.2.1.a: Use of predefined numeric types in package Standard.
- SPC 7.3.2.a: Comparison of access to subprogram values to not guaranteed.
- SPC 7.5.2.a: Exception handlers that handle Numeric_Error but not Constraint_Error.
- SPC 7.6.3.a: Use of machine code inserts.
- SPC 7.7.1.a: Use of the Form parameter in Text_Io.
- SPC 8.2.4.a: Use of subtypes as type marks when declaring generic formal objects of type
in out.Default SPC Enforcement
Rational Target-Compatibility Rules
The following rules check the compatibility of code developed on Rational Apex but intended for execution on other targets. These Little Tree Consulting (LTC) rules locate code segments that would be rejected as incorrect by another compiler or whose implementation-dependent meaning would probably change.
- LTC 101: Use of prede\xde ned types. Use of types in package Standard is non-portable.
- LTC 102: Use of external interfaces. Use of Ada interfaces outside project development libraries are reported since these may not be downloaded to the target and units that rely on them will not compile. The compatibility/development libraries file lists all project development subsystem. Subsystems not in this list are reported.
- LTC 103: Use of prompts. Rational Apex prompts are accepted by the Rational compiler but are not a legal part of the Ada language.
- LTC 104: Use of duplicate unit names. Existence of duplicate library-unit names in a simple application library is not legal.
- LTC 105: Use of unknown pragmas. Use of pragmas not recognized by the target compiler will not generate an error, but the pragma will not have the desired effect. This will also locate pragmas whose name is simply misspelled. The list of acceptable pragmas is stored in the known_pragmas file in the compatibility directory of the current configuration.
- LTC 106: Use of reserved names. Use of any reserved name of the target compiler will not be flagged as an error in Rational Apex. Reserved names are defined in the compatibility/reserved_names file.
- LTC 107: Unchecked_Conversion size mismatch. The Unchecked_Conversion function can be instantiated with two types that do not have the same size in Rational Apex. This is not accepted by most target compilers. Computation of size is governed by values in the type_sizing_file and type_sizing_name_map files.
- LTC 108: Correct declaration order of subprograms when inlined. Some compilers require that the body of an inlined subprogram appear before any call to that subprogram. Not Recommended by LTC (this rule is compiler dependent).
- LTC 109: Use of non-predefined language attributes. Use is non-portable. Note that the set of predefined attributes are different for Ada 83 and Ada 95 code.
- LTC 110: Use of non-predefined language pragmas. Note that the set of predefined pragmas are different for Ada 83 and Ada 95 code. This rule differs from LTC 105 in that the user can specify the precise list of pragmas that a particular target compiler supports with LTC 105.
Default LTC Enforcement
Little Tree Consulting's Software-Quality Guidelines
The following rules form the set of quality standards checks recommended by Little Tree Consulting. The rules have been divided into ten categories:
- Code Correctness
- Maintainability
- Efficiency
- Readability
- Portability
- Program Structure
- Program Format
- Real Time Restrictions (Annex D, Ravenscar)
- Safety and Security Restrictions (Annex H)
- SPARK Ada Subset Restrictions
Note: Although each rule is assigned to a specific category, several have implications in more than one quality objective. An attempt was made to assign each rule to the most appropriate category. Not all rules will apply to all projects; inappropriate rules can be disabled. Some rules are either similar to or duplicates of the SPC rules. Some SPC rules and other customer-specific rules that have been added to the rule library over time are not recommended by Little Tree Consulting but are included for completeness. All of these rules are Not_Enforced by default. If it is unclear why a particular rule should be enforced within your project, do not enable it in the rule_enforcement file.
Code Correctness
Checks in this category identify Ada constructs that have a higher risk of being an error. Not all identified constructs will be errors, but each should be further verified for correctness.
- LTC 201: Potential for divide by zero. Use of divide operators where the type of the dividend includes the value zero in its range can result in Numeric_Error when the value is actually zero.
- LTC 202: Use of 'ADDRESS on dynamic objects. Dynamic objects (that is, parameters and local subprogram variables) have an address on the stack, but the validity of that address will change as soon as the subprogram exits and the stack frame is removed. This makes it dangerous to use address attributes on dynamic objects.
- LTC 203: Use of 'ADDRESS on constants. Constants often have no specific address in memory. Constant values can be folded directly into assembly instructions, giving them no valid address.
- LTC 204: Static violations of constraints. Assignment of a string, integer, or real literal to a variable or parameter can violate that object's constraints. Such assignments will always raise a Constraint_Error exception when the program is executed.
- LTC 205: Inconsistent representation specifications. Since representation specifications are not completely checked for consistency by the Rational host compiler, they can be inconsistent and still compile without error or warning. The following inconsistencies are checked:
- Length clauses that are too small to contain values of the type represented.
- Values in representation specifications that must be static and are not.
- Values in the enumeration representation speci\xde cation that are not in ascending order.
- Components of record representations that are speci\xde ed more than once.
- Components of record representations that are not speci\xde ed in the representation clauses. Since this is allowed, it will commonly be recognized as a warning.
- Components that are an even number of bytes in size (characters and integers, for example) that are not byte-aligned in the representation specification. This will lead to inef\xde ciencies in the manipulation of this component. Note that byte size is de\xde ned in the Type_Sizing package.
- Bit ranges in the representation speci\xde cation for a component that overlaps with bit ranges from a previous component.
- A bit size allocated for a speci\xde c record component that is too small for that component's size.
- LTC 206: Function paths with no return or raise statement. Functions must either return a value or raise an exception. This will check that all program paths and exception handlers contain a return statement or an explicit raise statement.
- LTC 207: Exception handlers that handle Numeric_Error but not Constraint_Error. The Ada 83 language definition allows the compiler to also raise Constraint_Error whenever the Numeric_Error exception is specified. Therefore, programs should handle both exceptions to be safe. (also SPC 7.5.2.a)
- LTC 208: Operator rename of a different designator. When operators are renamed, they should introduce the same designator as the operator that has been renamed. Renaming "<" as ">" is an example of this error.
- LTC 209: Use of the "=", "/=", "<", and ">" operators with real operands instead of "<=" and ">=". Equality for real values is not precisely defined in Ada. Equality is better defined by saying that the difference between two values is less than some epsilon. (also SPC 5.5.6.a, SPARK 5.4.3)
- LTC 210: Use of limited private types that are not self-initializing. An object declaration of a limited private type should receive a reasonable initial value since it may not be possible to externally assign one before it is used.
- LTC 211: Use of allocators without an exception handler for Storage_Error in the local scope. Since any allocator can exhaust the available space of the collection, use of allocators should be limited and the "out of memory" case handled locally. (also SPC 5.4.5.i)
- LTC 212: Absence of an exception handler in the main loop of a task. Without an exception handler, any exception raised within the task, or propagated from subprograms that the task calls, could force the task to terminate. Even if this is the desired effect, this should be performed in a more orderly, explicit manner. (also SPC 6.3.1.a)
- LTC 213: Use of functions in the same context to initialize object declarations. Function calls, especially to functions declared in the local context, that are used to initialize variables may result in an elaboration error since the body of the function has not been elaborated at the point of call. (also SPC 5.9.6.f)
- LTC 214: Use of subtypes as type marks when declaring generic formal objects of mode in out. The Ada language definition does not enforce the checking of subtypes used in generic formal parameters. Instantiations can provide actual parameters that do not match the subtypes constraints. Assignments within the generic will violate the constraints of the actual and thus raise the Constraint_Error exception. (also SPC 8.2.4.a)
- LTC 215: Use of null statements. Null statements are often used early in development as placeholders to defer implementation of code segments. These null statements can be forgotten later in the development, leading to unimplemented requirements. This check locates all null statements in order to verify that they truly mean "in this case do nothing" and are not simply leftover placeholders.
- LTC 216: Use of any attributes specified as prohibited. This list is located in a new configuration-policy file called standards_conformance/prohibited_attributes. Each prohibited attribute should be listed in this file, one name to a line. The default content of the prohibited_attributes file lists the names `CALLABLE, `TERMINATED, `COUNT, and `UNCHECKED_ACCESS. (also SPC 6.2.3.a and 5.9.3.a)
- LTC 217: Use of attribute names as record components. If the name Size is used for a discriminant or record component of type Integer, then an easy typing mistake can be made (that is, R'Size versus R.Size) with dramatically different semantics. The names Constrained when used as a Boolean component and Address when used with the
System.Adress type share this potential problem.- LTC 218: Use of pragma Suppress. Use of this pragma (eliminating constraint checking) can be extremely dangerous and should be used with great care. (also SPC 5.9.5.a)
- LTC 219: Calls to non-local subprograms in elaboration code. This can result in elaboration order problems. Entry calls to local and non-local tasks are also reported since they can cause problems during elaboration.
- LTC 220: In out parameter inconsistencies. Parameters with mode in out that are not set in the body of the subprogram could be changed to mode in. In out parameters that are not used could be changed to mode out. (also SPC 5.2.4.b)
- LTC 221: Protected types should not invoke blocking operations in their execution closure. Blocking operations include select statements, accept statements, entry calls, delay statements, abort statements, external calls to protected subprograms, or external requeues. (also SPC 5.9.9.a)
- LTC 222: References to non-local variables in select guards should not be made since references will not be synchronized. (also SPC 6.2.4.c)
- LTC 223: Task bodies that do not have a when others exception handler can terminate abnormally.(also SPC 6.3.4.a)
- LTC 224: Comparison of access to subprogram values to not guaranteed. (also SPC 7.3.2.a)
- LTC 225: System.Address_To_Access_Conversions should be used with care.
- LTC 226: The raising of exceptions through the Ada.Exceptions.Raise_Exception procedure can be risky when an Exception_Id is used because that exception may not be visible in that context.
- LTC 227: External references made in the elaboration block of a package body must also have a pragma elaborate (<Unit_Name>); for the referenced external unit. This can avoid elaboration problems with some compilers.
- LTC 228: Variable declarations that do not have an explicit initial value can lead to uninitialized variables.
- LTC 229: Use of a when others exception handler whose statement body is null may be inappropriate in that they catch all exceptions but provide no further processing of the conditions that led to the exception.
- LTC 230: Instantiation of the predefined generic packages Direct_Io and Sequential_Io with an access type or composite type that contains an access type is an invalid use of these packages.
- LTC 231: The use of type conversions whose target type has a constraint that is smaller that the source expression.
- LTC 232: The use of access type object declarations in local subprogram blocks that are not deallocated with unchecked_deallocation somewhere in that block. (Also SPC 5.9.2b)
- LTC 233: Use of logical operators on model number types whose modulus is not a power of two
Maintainability
Checks in this category are seldom problems in their current form but have a high risk of introducing an error when changes are made to other constructs they implicitly depend on.
- LTC 301: Use of when others in an exception handler. Such handlers are a catchall and may be appropriate in some cases. An example may be to guard a task from being terminated by some unknown exception (see LTC 213). It is better practice to explicitly handle all potential exceptions. (also SPC 5.8.2.a)
- LTC 302: Use of when others in a case statement. When new values are added to the discrete type definition evaluated by the case, they will automatically be handled by the others clause without warning to the user. Such changes may result in errors being introduced into other parts of the program. (also SPC 5.6.3.a)
- LTC 303: Use of an enumeration literal range as a choice in a case statement. Use of such constructs have the same problems as those in LTC 302 above. (also SPC 5.6.3.b)
- LTC 304: Use of others choices in aggregates whose index is enumerated. Record aggregates and array aggregates with enumerated index types should not use others. This can lead to unintended component values when a component is added to the record or a value is added to the enumerated range.
- LTC 305: Declaration of array types whose index type is not explicitly declared. Explicit index types are much more maintainable than literal ranges. They allow for declaration of index variables that have the precise range of the array itself.
- LTC 306: Absence of named parameter association on all subprogram and entry calls. Named parameter association is more explicit and avoids potential errors when subprogram parameters are reordered. It is often more readable as well. (also SPC 5.2.2.a)
- LTC 307: Absence of named association in record aggregates. Named association in record aggregates is more explicit and avoids potential errors when record components are reordered. It is often more readable as well. (also SPC 5.6.10.c)
- LTC 308: Absence of named association when instantiating generics. Named association in generic instantiations is more explicit and avoids potential errors when formal generic parameters are reordered. It is often more readable as well. (also SPC 5.2.2.b)
- LTC 309: Use of numeric literals in nondeclarative parts of the program. Ada defines named numbers to provide a single point of definition for literals. When a value is changed, all references are likewise changed. Use of literals sprinkled through the code requires updates to each, which is often error-prone. (also SPC 3.2.6.j)
- LTC 310: Use of default parameters. When defaults are present in subprogram parameters, callers can avoid explicit entry of values for these parameters. If changes are made to the subprogram parameter specification (that is, reordering and/or changes to default values), calls may no longer have their intended values. (also SPARK 6.5.1)
- LTC 311: Use of raise statements with no named exception (reraise). Raise statements without an explicitly named exception can be dangerous when changes are made to the exception handlers in which they reside. Raise statements should explicitly name the exception raised.
- LTC 312: Absence of named association in array aggregates. Named association in array aggregates is more explicit and readable.
Efficiency
Checks in this category can negatively impact the execution speed, overall size, and/or memory utilization of a program.
- LTC 401: Use of recursive subprograms. Use of recursion can impact the amount of stack space required to execute certain algorithms, especially when that recursion is potentially unbounded. This is particularly important for real-time programs with strict memory-allocation requirements for tasks in the program. This rules checks only for direct recursion (calling oneself). Use the Locate_Recursive_Subprograms command to find other forms of recursion. (also SPARK 6.7.2)
- LTC 402: Use of access types. Use of access types requires dynamic allocation of memory. Their use carries the additional implication of handling potential Storage_Error exceptions and/or developing a memory-management strategy. These are often unacceptable for real-time applications. (also SPARK 5.2.3)
- LTC 403: Use of the or and and operators instead of short-circuit forms. Often, use of and then and or else (that is, short-circuit forms) will be more runtime-efficient since the second half of the expression need not be evaluated when the first part determines the outcome. (also SPC 5.5.5.a)
- LTC 404: Use of the package Text_Io. The package Text_Io is a very large package that may require too much memory on smaller targets. Since Text_Io is often used in early development for testing, continued use in later phases may be a problem.
- Rule 405: If statement replaceable by case. Case statements can be more efficient than if statements with many conditional expressions. Not Recommended by LTC (unclear that an if statement is better).
- Rule 406: Not allocated.
- Rule 407: If statement used to set Boolean variable. The Boolean variable can be set directly with the conditional expression. Not Recommended by LTC (often the use of an if statement makes the set is easier to understand).
- Rule 408: Integer typed constants. Named numbers are preferable. Not Recommended by LTC (compiler dependent).
- Rule 409: Record component renames only to one level. This can be less efficient than direct selection. Not Recommended by LTC (compiler-dependent optimization).
- Rule 410: Selective wait statements with else part. Not Recommended by LTC (this construct is often very useful in some circumstances).
- Rule 411: The use of modular types when using bit-wise Boolean operators is preferred for efficiency reasons. Not Recommended by LTC (compiler dependent).
- LTC 412: Functions that return a type whose size in bytes is greater than the limit specified in the standards_conformance/return_type_limit file in the current configuration policy. Returning objects of large size from a function is often very inefficient.
- LTC 413: Functions that return unconstrained types or types whose size is not statically computable. Returning unconstrained objects from a function is often very inefficient. (also SPARK 6.5.3)
- LTC 414: Record components with default initialization values can result in excessive elaboration code. (also SPARK 5.5.2)
Readability
Checks in this category directly impact a user's ability to read and easily understand a program.
- LTC 501: Declarations using names from package Standard. To avoid confusion, the identifiers of package Standard (that is, Integer, String, and so on) should not be used as the name of declarations in the application program. (also SPARK 7.7.3)
- LTC 502: Use of unapproved renames. Renames should be used consistently in a program. One method of enforcing this rule is to allow renames only from a preapproved list. This list is stored in the approved_renames file in the standards_conformance subdirectory of the current configuration. (also SPC 5.7.2.f)
- LTC 503: References to renamed items through their original name. When a rename of a package is present, reference to that package should be made only with the rename and not with the original declaration's name. (also SPARK 7.7.5)
- LTC 504: Use of any use clause not on an approved list. Wide use of use clauses tends to reduce readability by allowing declarations to be referenced without full qualification. This list is stored in the allowed_use_clauses file in the standards_conformance directory of the current configuration. (also SPC 5.7.1.b, SPARK 7.7.1)
- LTC 505: Use of abbreviations that are not on an approved list. Identifier segments that are misspelled and not in the approved abbreviation list (stored in a file) are errors. The list of allowed abbreviations is stored in the allowed_name_abbreviations file in the standards_conformance directory of the current configuration. (also SPC 3.1.4.f)
- LTC 506: Use of the not operator. Negative expressions are generally less understandable than positive expressions, especially when double negatives are present (example: not (Uninitialized)). (also SPC 5.5.4.a)
- Rule 507: Order of default parameters. (also SPC 5.2.3.b) Not Recommended by LTC (unclear why this is better).
- Rule 508: Exit statements not naming a loop. (also SPC 5.1.3.a) Not Recommended by LTC (often a simple exit is clearer).
- Rule 509: Parameters in mode order. Not Recommended by LTC (parameter mode should not be the most important criteria in establishing order).
- Rule 510: Nested blocks that are not named. (also SPC 5.1.2.a) Not Recommended by LTC (unclear why this makes the code easier to understand).
- Rule 511: Nested loops that are not named. (also SPC 5.1.1.a) Not Recommended by LTC (unclear why this makes the code easier to understand).
- Rule 512: Parameters without explicit modes. (also SPC 5.2.4.a) Not Recommended by LTC (implied in mode is clear and functions will have unnecessary mode specifications).
- Rule 513: Large loops that are not named. Large loops are those whose number of lines exceeds the limit defined in the standards_conformance/named_loop_size file. Not Recommended by LTC (unclear why naming makes large loops easier to understand).
- LTC 514: Unqualified references. All references to non-local, non-operator declarations should be properly qualified with the name of the package in which the declaration resides. References in subunits to ancestor declarations are considered local. The check locates non-operator references where a use clause or child unit relationship has been used to remove the need for qualification. (also SPARK 7.2.1)
- LTC 515: All complex expressions should be fully parenthesized. The expressions a+b*c would generate a violation whereas (a+b)*c or a+(b*c) would not. (also SPC 5.5.3.a).
- LTC 516: Loops that contain exit statements that are also not named. (also SPC 5.1.1.b).
- LTC 517: Declared names must follow a set of naming conventions specified in the standards_conformance/naming_conventions file. Possible naming conventions are described on page 37.
- LTC 518: The number of dot selections must not be greater than the limit specified in the standards_conformance/name_selection_limit file. If the limit specified were 2, the name reference Pkg.Nested.Obj.Comp would violate this rule.
- LTC 519: Unqualified references variant. Same as LTC 514 above but considers unqualified references to declarations in ancestor units in both subunits and child units to be local and not violations of this rule.
Portability
Checks in this category locate constructs that will negatively impact the possibility of porting a program to another compilation system.
- LTC 601: Use of unchecked conversion on unconstrained types. Unchecked conversion of unconstrained types may have unpredictable results, making its behavior nonportable.
- LTC 602: Use of delay statements with zero duration. Null delays are often used to force a return to the scheduler without actually imposing a delay of the execution of the local task. Some compilers interpret this as a no-op. Reliance on a particular implementation of this construct makes the program less portable.
- LTC 603: Use of representation specifications on derived types. Some compilers prohibit the use of such constructs.
- LTC 604: Use of Text_Io Form parameters. Use of this implementation-dependent parameter on the Create and Open procedures may not be portable to other systems. (also SPC 7.7.1.a)
- LTC 605: Absence of a representation clause specifying the collection size for access types. Without a specific allocation of memory to collections, the default chosen on another target could be either less or more than the required amount. Both can be a problem. (also SPC 5.4.5.h)
- LTC 606: Absence of a representation clause to specify the stack size for tasks. Without a specific allocation of memory for each task's stack space, the default chosen on another target could be either less or more than the required amount. Both can be a problem.
- LTC 607: Main programs with parameters. This is not supported by most compilers. (also SPC 7.1.4.a)
- LTC 608: Use of machine code inserts. This is clearly target dependent. (also SPC 7.6.3.a)
Program Structure
Checks in this category locate constructs that can reduce the structural integrity of a program.
- LTC 701: Subprograms with McCabe cyclomatic complexity over n. The McCabe metric is one method of determining program complexity. Subprograms or task bodies with a McCabe cyclomatic complexity over n may require some redesign to be easily understandable and/or easily testable. The value of n is stored in the mccabe_complexity_limit file in the standards_conformance directory of the current configuration. The default is 10, a limit suggested by McCabe in his article describing the use of this metric.
- LTC 702: Use of the abort statement. Asynchronous aborts of tasks can lead to inconsistencies when the aborted task was in the middle of some operation. Calling an entry to perform an orderly shutdown is more reliable. (also SPC 6.3.3.a, SPARK 6.1.3)
- LTC 703: Use of goto statements. Unstructured program jumps make a program's control flow harder to understand, test, and modify. (also SPC 5.6.7.a, SPARK 6.1.1)
- LTC 704: Use of anonymous types. Anonymous types cannot be used as a whole (that is, as parameters or in assignment to other arrays). This makes their use less flexible than the declaration of an explicit array type. (also SPC 5.3.2.a)
- LTC 705: Explicit raising of exceptions that are caught in the local scope (that is, used as a goto). Use of exceptions in this manner is another form of an unstructured program jump. It makes programs harder to understand, test, and modify. (also SPC 5.8.1.d)
- LTC 706: Raising of predefined exceptions. This adds confusion as to the source of the exception. Declaration of application exceptions keeps system run-time and application errors separate. (also SPC 4.3.1.j)
- LTC 707: Declaration of exceptions in a nonvisible part of the program. Nonvisible declarations can be very dangerous since they can only be handled (except with when others) within the scope of the declaration. Unintended propagation outside this scope may impact remote sections of the code and be a difficult error to find. (also SPC 4.3.1.c)
- LTC 708: Functions with more than one return statement in the body. Subprograms with more than one exit point are more difficult to understand and modify. (also SPC 5.6.8.a)
- LTC 709: Procedures containing return statements. Subprograms with more than one exit point are more difficult to understand and modify. (also SPC 5.6.8.a)
- LTC 710: Functions with side effects (that is, that update variables outside their scope). Functions should compute and return some value. Side effects make such functions more difficult to understand and use. (also SPC 4.1.4.b)
- LTC 711: Use of exit statements in while and for loops. In these cases, there is multiple and perhaps conflicting termination. (also SPC 5.6.4.d)
- LTC 712: Presence of more than one exit point from a loop. This loops are more difficult to understand and modify. (also SPC 5.6.4.e)
- LTC 713: Variables declared in the visible part of a package. These variables can be globally updated by any unit that withs that package. This increases program coupling, making programs harder to understand and maintain. (also SPC 4.1.8.a)
- LTC 714: Use of radices other than 1, 8, or 16. Values with other radices are extremely hard for users to compute and understand.
- LTC 715: Declaration of constants in a dynamic scope. Declarations of constants within subprograms and tasks can lead to redundant definition. It can also introduce inefficiencies when the constant is a composite value or is not statically initialized. Constants should be declared in a static scope.
- LTC 716: Unchecked_Conversion should be used with care. (also SPC 5.9.1.a)
- LTC 717: Unchecked_Deallocation should be used with care. (also SPC 5.9.2.a)
- Rule 718: Use of conditional entry calls. (also SPC 6.2.5.a) Not Recommended by LTC (often a useful construct).
- Rule 719: Derived types without constraints. (also SPC 5.3.1.d) Not Recommended by LTC (often constraints are required).
- Rule 720: Dynamically allocated tasks. (also SPC 6.1.5.a)
- Rule 721: Tasks without terminate alternatives. (also SPC 6.3.2.d) Not Recommended by LTC (often a useful and/or necessary construct).
- Rule 722: Use of exit, not exit when. (also SPC 5.6.5.b) Not Recommended by LTC (simple exist is often clearer).
- Rule 723: Use of pragma Shared.
- Rule 724: Subtype declarations without constraints. (also SPC 5.3.1.b) Not Recommended by LTC (subtypes without constraints can be used to introduce renamed types).
- Rule 725: Visible task declarations. (also SPC 4.2.4.a) Not Recommended by LTC (could be simpler and more efficient construction than an elaborate skin).
- Rule 726: Else parts when exception raised. Not Recommended by LTC (exception may not always be raised).
- Rule 727: Use of delay statements. (also SPC 6.1.7.b) Not Recommended by LTC (often a useful or required construct).
- Rule 728: Use of enumeration rep specs. Not Recommended by LTC (could be required).
- Rule 729: Use of complex expressions. Complex expressions are those whose depth is greater than the limit specified in the standards_conformance/expression_depth_limit file. Not Recommended by LTC (difficult to define complex).
- Rule 730: Use of fixed-point types. Not Recommended by LTC (often a useful or required construct).
- Rule 731: Use of attribute clauses. Not Recommended by LTC (often a useful or required construct).
- Rule 732: Use of priorities. Not Recommended by LTC (often a useful or required construct).
- Rule 733: Subprogram nesting greater than limit. This limit is defined in the standards_conformance/subprogram_nesting_limit file. Not Recommended by LTC (if nesting is appropriate, why limit it?).
- Rule 734: Use of tasking. Not Recommended by LTC (Often a useful or required construct). (also SPARK 4.2.1)
- Rule 735: Use of address clauses. (also SPC 5.9.4.a) Not Recommended by LTC (often a useful or required construct).
- Rule 736: Package nesting greater than limit. This limit is defined in the standards_conformance/package_nesting_limit file. Not Recommended by LTC (if nesting is appropriate, why limit it?).
- Rule 737: Use of record rep clauses. Not Recommended by LTC (often a useful or required construct).
- Rule 738: In Rational Apex, some units can be exported from a subsystem view via an export set specified in the view's switch file. Exported units are available for external use by units in other subsystems. If a declaration from a non-exported unit is renamed in an exported unit, then that declaration is externally available even though its export was not intended. Declarations that are re-exported in this manner violate this rule. Declarations that are re-exported in the same manner from other subsystems also violate this rule.
- Rule 739: External use of a declaration that is exported in the manner described in Rule 738 (that is, a reference to a renamed declaration from a non-exported unit). External use is defined as a reference appearing in a subsystem other than that in which the renamed declaration appears.
- Rule 740: Private part definitions should not have extraneous declarations in them. They should include only declarations that are completions of private types, completions of deferred constants, or declarations that are necessary to fully specify a private or deferred constant completion.
- Rule 741: Use of library-level subprograms that are not main programs is discouraged. (also SPC 4.1.1.b)
- Rule 742: The use of child units is encouraged over the use of subunits by the SPC guidlines. (also SPC 4.1.1.c) Not Recommended by LTC (both are useful constructs).
- Rule 743: The use of private child units and a with in the parent body is encouraged over the use of nested packages by the SPC guidlines. (also SPC 4.1.1.g) Not Recommended by LTC (both are useful constructs).
- LTC 744: Subtype nesting that exceeds the limit specified in the standards_conformance/ subtype_nesting_limit file. That is, if a subtype declaration specifies another subtype as its type mark, and that subtype also specifies a subtype as its type mark, the amount of nesting increases with each chained reference. This rule is violated if the number of occurrences exceeds the specified limit.
- LTC 745: Unnecessary type conversions. If the expression being converted is already of the same base type as the type mark of the conversion, then the type conversion is unnecessary.
- LTC 746: Access type declarations that do not have an associated `Storage_Pool attribute clause.
- LTC 747:User-defined exceptions declarations. Not Recommended by LTC
- LTC 748: Modifications located in child units to variables located in the private part of an ancestor unit.
- LTC 749: Inappropriate declarations located in subprogram and local blocks. For this rule, inappropriate declarations are all declarations other than variable declarations, access type declarations, and subprogram declarations nested within a subprogram block. Variable declarations are appropriate as a way of allocating temporary storage for computation. Access types are appropriate because the storage pool associated with the access type can be reclaimed when the block is exited.
- LTC 750: Functions should be purely computational. External updates and calls to procedures within function bodies are considered side-effects. Functions should compute their return value from input parameters and local constants and not have side effects. This is a companion rule to LTC 710 (functions with side effects). LTC 710 reports bodies that have at least one side-effect. This rule reports all side-effects within functions.
Program Format
Checks in this category locate constructs that do not match formatting requirements and therefore cannot be enforced by the pretty printer.
- Rule 801: If a list has more than three items, each item should be placed on a separate line. Not Recommended by LTC (difficult to maintain, unclear advantages).
- Rule 802: Alphabetical context clause order. Context clauses are easier to file if they are in alphabetical order.
- Rule 803: Alphabetic rename clause order. Not Recommended by LTC (difficult to maintain, unclear advantages).
- Rule 804: Use of multiple names in a single context clause. It is often cleaner to have only one name per context clause.
- Rule 805: Use of multiple names in declarations. Violations will be located within constant, variable, record component, discriminant, subprogram-parameter, generic formal object, and exception declarations. It is often cleaner and more flexible to have one name per declaration.
- Rule 806: Units whose line count is greater than the maximum size specified in the file named maximum_unit_size in the standards_conformance directory of the current configuration.
- Rule 807: Subprograms whose line count is greater than the maximum size specified in the file named maximum_subprogram_size in the standards_conformance directory of the current configuration.
Real Time Restrictions (Annex D, Ravenscar)
This section identifies restrictions listed in Annex D, "Real-Time Systems" of the Ada 95 LRM. These restrictions prohibit the use of certain Ada constructs that might negatively impact the reliability of Ada programs for safety critical applications.
This section also defines rules that check the coding restrictions defined in the Ravenscar Tasking Profile. The complete set of rules are listed in the standards_conformance/ravenscar_enforcement file of the default configuration policy.
- LTC 1101: Locates tasks that are declared in a dynamic scope.
- LTC 1102: Locates objects with controlled parts or access types that designate such objects that are not declared at the library level.
- LTC 1103: Locates all abort statement instances.
- LTC 1104: Locates selective accept statements with terminate alternatives.
- LTC 1105: Locates dynamic allocation of tasks.
- LTC 1106: Locates usage of the predefined Dynamic_Priorities package.
- LTC 1107: Locates usage of the predefined Asynchronous_Task_Control package.
- LTC 1108: Locates select statements whose number of alternatives is greater than the limit specified in the standards_conformance/maximum_select_alternatives file of the current configuration policy.
- LTC 1109: Locates tasks whose number of entries is greater than the limit specified in the standards_conformance/ maximum_task_entries file of the current configuration policy.
- LTC 1110: Locates protected types and objects whose number of entries is greater than the limit specified in the standards_conformance/maximum_protected_entries file of the current configuration policy.
- LTC 1111: Locates all task type and task object declarations that are not declared at the compilation-unit level. This is a Ravenscar Tasking Profile rule.
- LTC 1112: Locates all protected objects that define more than one entry. This is a Ravenscar Tasking Profile rule.
- LTC 1113: Locates all entry barriers and are not simple Boolean variables. This is a Ravenscar Tasking Profile rule.
- LTC 1114: Locates all requeue statements. This is a Ravenscar Tasking Profile rule.
- LTC 1115: Locates all select statements. This is a Ravenscar Tasking Profile rule.
- LTC 1116: Locates all unchecked deallocation of tasks. This is a Ravenscar Tasking Profile rule.
- LTC 1117: Locates all usages of the Ada.Task_Attributes package. This is a Ravenscar Tasking Profile rule.
Safety and Security Restrictions (Annex H)
This section identifies restrictions listed in Annex H, "Safety and Security" of the Ada 95 LRM. These restrictions prohibit the use of certain Ada constructs that might negatively impact the reliability of Ada programs for safety critical applications
- LTC 1001: Locates instances of protected objects and types. (also SPARK 4.2.2)
- LTC 1002: Locates all allocator expressions.
- LTC 1003: Locates allocator expressions that appear in subprograms, generic subprograms, tasks, and entry bodies.
- LTC 1004: Locates generic instantiations that appear in subprograms, generic subprograms, tasks, and entry bodies.
- LTC 1005: Locates usage of the predefined package Unchecked_Deallocation.
- LTC 1006: Locates exception raise statements and exception handlers. (also SPARK 6.1.1)
- LTC 1007: Locates all definitions or usage of floating point types.
- LTC 1008: Locates all definitions or usage of fixed point types.
- LTC 1009: Locates usage of the predefined package Unchecked_Conversion.
- LTC 1010: Locates declarations of access subprograms.
- LTC 1011: Locates use of the `Unchecked_Access attribute.
- LTC 1012: Locates usage of the `Class attribute.
- LTC 1013: Locates references to the predefined Io packages Sequential_Io, Direct_Io, Text_Io, Wide_Text_Io, or Stream_Io.
- LTC 1014: Locates all usages of delay statements. (also SPARK 6.1.4)
- LTC 1015: Locates references to the predefined package Calendar.
- LTC 1016: Locates instances of recursive subprograms.
SPARK Ada Subset Restrictions
This section identifies restrictions defined for the SPARK Ada subset programming language as specified in "High Integrity Ada, The SPARK Approach" by John Barnes. An additional sixteen rules from other sections of the Ada Analyzer rule library make up the complete set of SPARK coding violation restrictions. These restrictions prohibit the use of certain Ada constructs in the SPARK subset.
- LTC 1201: Locates the declaration of generic units (4.2.3).
- LTC 1202: Locates library subprograms that are not main subprograms (4.2.4).
- LTC 1203: Locates all violations of the visibility rules associated with private child units. In SPARK, private child units are not visible to other public siblings (4.2.5).
- LTC 1204: Locates all violations of the visibility rules associated with public child units. In SPARK, a package body cannot references its own public children (4.2.6).
- LTC 1205: Locates packages that are nested in other package specifications (4.2.7).
- LTC 1206: Locates packages that initialize non-local own variables (4.2.8).
- LTC 1207: Locates all usages of SPARK reserved words (4.3.1).
- LTC 1208: Locates use of real based literals (4.3.2).
- LTC 1209: Locates references to the predefined Wide_Character type (4.3.3).
- LTC 1210: Locates references to the predefined Wide_String type (4.3.4).
- LTC 1211: Locates use of anonymous types or subtypes. In SPARK, all type definitions must have an explicit name (5.2.1).
- LTC 1212: Locates declarations of derived types (5.2.2).
- LTC 1213: Locates declarations of modular types (5.2.4).
- LTC 1214: Locates declarations of decimal types (5.2.5).
- LTC 1215: Locates use of type extension (5.2.6).
- LTC 1216: Locates declaration of discriminant records (5.2.7).
- LTC 1217: Locates all constraints that are not static (5.2.8).
- LTC 1218: Locates the use of null ranges (5.2.9).
- LTC 1219: Locates overloaded enumeration literals (5.3.1).
- LTC 1220: Locates declaration of user defined character types (5.3.2).
- LTC 1221: Locates references to predefined scalar types other than Integer (5.4.1).
- LTC 1222: Locates references to predefined real types other than Float (5.4.2).
- LTC 1223: Locates declarations of tagged types (5.5.1).
- LTC 1224: Locates string subtypes whose lower bound is not 1 (5.5.3).
- LTC 1225: Locates use of array slices or assignments that cause the bounds of the array to slide (5.5.4).
- LTC 1226: Locates aggregates with mixed named and positional notation used for component specification (5.6.1).
- LTC 1227: Locates use of others clauses in record aggregates (5.6.2).
- LTC 1228: Locates aggregates that are not qualified with a type mark (5.6.3).
- LTC 1229: Locates user declaration of operators (5.7.1).
- LTC 1230: Locates use of infix operators (5.7.2).
- LTC 1231: Locates violations of array equality restrictions (5.8.1).
- LTC 1232: Locates use of type conversion with out parameters at the point of call (5.8.2).
- LTC 1233: Locates non-static expressions in declarations (5.9.1).
- LTC 1234: Locates use of block statements (6.1.1).
- LTC 1235: Locates all usage of statement labels (6.1.3).
- LTC 1236: Locates exit statements that violate SPARK restrictions (6.3.1).
- LTC 1237: Locates violation of restrictions associated with return statements (6.4.1).
- LTC 1238: Locates declarations of overloaded subprograms (6.5.2).
- LTC 1239: Locates subprogram calls that mix named and positional parameter notation (6.7.1).
- LTC 1240: Locates violations of SPARK restrictions on subprogram specifications (7.1.1).
- LTC 1241: Locates violations of where use type clauses may appear (7.7.2).
- LTC 1242: Locates violations of SPARK renaming restrictions (7.7.4).
- LTC 1243: Locates references to predefined packages other than Standard and Ada.Charactes.Latin1 (8.4.1).
- LTC 1244: Locates unqualified references including local references to ancestor units in both subunits and child units. This rule is similar to LTC 514 but reports unqualified references to local ancestor declarations in both child units and subunits.
Default LTC Enforcement
Little Tree Consulting's Metrics Library
The following form the initial metrics library for the Ada Analyzer. Although limited in its initial size, it is expected to grow over time. It is also expected that customers will add their own metrics to the library using the Ada Analyzer to automate collection and comparison of those metrics. The current metrics are divided into three categories:
- Line (source lines of code) Counting
- Subprogram Metrics
- CMVC Metrics
Line Counting
Metrics in this category provide various forms of counting source lines of code (SLOC). Note that these metrics are text-based and dependent only on the image of the line, not its Ada semantics.
- Metric 101: Number of carriage returns (total number of lines in the ASCII file).
- Metric 102: Number of blank lines (lines containing only blank or tab characters).
- Metric 103: Number of comment lines (lines whose first non-blank, non-tab characters are "--").
- Metric 104: Number of non-blank, non-comment lines (computed as the number of carriage return lines minus the number of blank lines minus the number of comment lines).
- Metric 105: Number of lines ending with a semicolon character. (Number of lines that end in a `;' character plus lines that end in a semicolon but are followed by a comment. Note that this does not necessarily correspond to Ada constructs that have a semicolon.)
Subprogram Metrics
Metrics in this category measure the subprogram complexity.
- Metric 201: Number of subprogram execution paths.
- Metric 202: McCabe complexity metric.
- Metric 203: A variant of the McCabe metric that adds the McCabe metric of any nested subprograms to the McCabe metric of the parent subprogram. Note that this metric is not enabled by default in the metrics collection file of the default configuration policy.
- Metric 204: Number of executable statements (that is, the number of statements, excluding null statements, in a subprogram). This metric can be used to estimate execution code size or estimate the number of hours required for testing and maintenance.
- Metric 205: The essential complexity as defined in the below-referenced paper. Basically, this metric is the same as cyclomatic complexity but with entire control structures eliminated from the count if they contain no unstructured control-flow constructs.
- Metric 206: Module design complexity as described in the below-referenced paper. Basically, this metric computes the number of execution paths on which there is a subprogram call to another module.
Note: The implementation of metrics 205 and 206 was based on a paper titled "Structured Testing: A Testing Methodology Using the Cyclomatic Complexity Metric" by Arthur H. Watson and Thomas J. McCabe, NIST Special Publication 500-235.
CMVC Metrics
Metrics in this category measure statistics related to configuration management.
- Metric 301: The Unit_Modifications metric will compute the number of times a unit has been changed within the current history. The CMVC database is consulted to count each separate modification to a unit. Note that this is not the number of versions or the number of times the unit has been checked out, but the number of textual changes made. Units with a large number of changes may require redesign to reduce the need for constant repair.
OO Metrics
Metrics in this category measure statistics related to Object Oriented programming.
- Metric 401: The Number of Methods metric will compute the total number of methods available for a class (both explicit and inherited).
- Metric 402: The Number of Attributes metric will compute the total number of attributes that constitute the data representation of a class. Both explicit and inherited attributes will be counted.
- Metric 403: The Depth of Inheritance metric will compute the depth of inheritance of a class. This depth is defined to be the number of derivations from parent class types to the base class type that is not derived.
- Metric 404: The Class Response metric will compute the response of a class. The response of a class is defined to be the number of methods from other classes called by the explicit methods of a class. Inherited methods are not scanned for calls and duplicate calls to the same method are counted only once.
- Metric 405: The Class Coupling metric will compute the coupling of a class. Coupling is defined to be the number of other classes referenced by the explicit methods and attributes of a class. Inherited methods and attributes and not scanned for references and duplicate references are counted only once.
- Metric 406: The Class Complexity metric will compute the McCabe cyclomatic complexity of a class. This is defined to be the sum of the McCabe cyclomatic complexities of all explicit methods of a class. Inherited methods are not included in this computation.
Halstead Metrics
Metrics in this category calculate Halstead metric definitions. Note that the utility of Halstead metrics has been questioned given the movement of current programming practice away from operator/operand-oriented programming towards more object-oriented and decision logic programming. Halstead metrics are included for completeness and to support those projects who have customer requirements to generate Halstead metrics. Each metric is collected for each compilation unit and on a system-wide basis
- Metric 501: Number of distinct operators (n1)
- Metric 502: Number of distinct operands (n2)
- Metric 503: Total number of operators (N1)
- Metric 504: Total number of operands (N2)
- Metric 505: Program Length (N = N1 + N2)
- Metric 506: Program Vocabulary (n = n1 + n2)
- Metric 507: Volume (V = N * log2 n)
- Metric 508: Difficulty (D = (n1 / 2) * (N2 / n2))
- Metric 509: Effort (E = D * V)
Default Status
| Rational Software Corporation
http://www.rational.com support@rational.com techpubs@rational.com Copyright © 1993-2000, Rational Software Corporation. All rights reserved. |
| |
|
|
|
|
|
 |
 |