Ada '83 Quality and Style:

Guidelines for Professional Programmers

Copyright 1989, 1991,1992 Software Productivity Consortium, Inc., Herndon, Virginia.

CHAPTER 7: Portability

Chapter 7 Summary

7.1 fundamentals

• Make considered assumptions about the support provided for the following on potential target platforms:
  • Number of bits available for type Integer (range constraints).
  • Number of decimal digits of precision available for floating point types.
  • Number of bits available for fixed-point types (delta and range constraints).
  • Number of characters per line of source text.
  • Number of bits for Universal_Integer expressions.
  • Number of seconds for the range of Duration.
  • Number of milliseconds for Duration'Small.
• Don't implicitly use an implementation limit.
• Use highlighting comments for each package, subprogram and task where any nonportable features are present.
• For each nonportable feature employed, describe the expectations for that feature.
• Use only a parameterless procedure as the main program.
• Create packages specifically designed to isolate hardware and implementation dependencies and designed so that their specification will not change.
• Clearly indicate the objectives if machine or solution efficiency is the reason for hardware or implementation dependent code.
• For the packages that hide implementation dependencies, maintain different package bodies for different target environments.
• Isolate interrupt receiving tasks into implementation dependent packages.
• Avoid the use of vendor supplied packages.
• Avoid the use of features added to the predefined packages that are not specified in the language definition.

7.2 numeric types and expressions

• Do not use the predefined numeric types in package Standard. Use range and digits declarations and let the implementation do the derivation implicitly from the predefined types.
• For programs that require greater accuracy than that provided by the global assumptions, define a package that declares a private type and operations as needed; see Pappas (1985) for a full explanation and examples.
• Know the Ada model for floating point types and arithmetic.
• Carefully analyze what accuracy and precision you really need.
• Do not press the accuracy limits of the machine(s).
• Comment the analysis and derivation of the numerical aspects of a program.
• Use named numbers or universal real expressions rather than constants of any particular type.
• Anticipate values of subexpressions to avoid exceeding the range of their type. Use derived types, subtypes, factoring, and range constraints on numeric types as described in Guidelines 3.4.1, 5.3.1, and 5.5.3.
• Use <= and >= to do relational tests on real valued arguments, avoiding the <, >, =, and /= operations.
• Use values of type attributes in comparisons and checking for small values.

7.3 storage control

• Do not use a representation clause to specify number of storage units.

7.4 tasking

• Do not depend on the order in which task objects are activated when declared in the same declarative list.
• Do not depend on a particular delay being achievable (Nissen and Wallis 1984).
• Never use a busy waiting loop instead of a delay.
• Design to limit polling to those cases where it is absolutely necessary.
• Never use knowledge of the execution pattern of tasks to achieve timing requirements.
• Do not assume a correlation between System.Tick and package Calendar or type Duration (see Guideline 6.1.5).
• Do not depend on the order in which guard conditions are evaluated or on the algorithm for choosing among several open select alternatives.
• Do not assume that tasks execute uninterrupted until they reach a synchronization point.
• Use pragma Priority to distinguish general levels of importance only (see Guideline 6.1.4).
• Avoid using the abort statement.
• Do not share variables.
• Have tasks communicate through the rendezvous mechanism.
• Do not use shared variables as a task synchronization device.
• Use pragma Shared only when you are forced to by run time system deficiencies.

7.5 exceptions

• Do not depend on the exact locations at which predefined exceptions are raised.
• Catch Numeric_Error exceptions with a Numeric_Error | Constraint_Error exception handler.
• Do not use a separate exception handler for Numeric_Error and Constraint_Error.
• Do not raise implementation-defined exceptions.
• Convert implementation defined exceptions within interface packages to visible user-defined exceptions.

7.6 representation clauses and implementation-dependent features

• Use algorithms that do not depend on the representation of the data and therefore do not need representation clauses.
• Use representation clauses when accessing interface data or when a specific representation is needed to implement a design.
• Avoid using package System constants except in attempting to generalize other machine dependent constructs.
• Avoid machine code inserts.
• Avoid interfacing Ada with other languages.
• Isolate all subprograms employing pragma Interface to implementation-dependent (interface) package bodies.
• Avoid pragmas and attributes added by the compiler implementor.
• Avoid dependence on Unchecked_Deallocation (see Guideline 5.9.2).
• Avoid using Unchecked_Conversion (see Guideline 5.9.1).
• Avoid the direct invocation of or implicit dependence upon an underlying host operating system or Ada run time support system.

7.7 input/output

• Use constants and variables as symbolic actuals for the Name and Form parameters on the predefined I/O packages. Declare and initialize them in an implementation dependency package.
• Close all files explicitly.
• Avoid performing I/O on access types.
• Minimize and isolate using the predefined package Low_Level_IO.