Ada Repair

Technical Specification

Ada Repair takes static analysis of coding violations a step further by automatically creating new versions of your programs that no longer contain violations. The resulting code is semantically equivalent to the original but with improved maintainability, consistency, and readability. For example, the following procedure call embedded in a case statement

Procedure Call

could be updated to add the missing named parameter association and the default parameter to the procedure call. The addition of named parameter association makes the call more readable and the addition of the default parameter reduces the risk of future defects when the default is changed for some reason. Expanding the case range and when others will make the software more robust and less prone to future defects.

The following repairs can be made to Ada software. Each update is a separate option that can be enabled when that repair is desired.

Code Modification Benefits
1. Add named parameter association to procedure calls. Makes procedure calls more readable and maintainable.
2. Add named association to aggregates. Makes aggregates more readable and maintainable.
3. Add named association to generic instantiations. Makes generic instantiations more readable and maintainable.
4. Add explicit default parameters to calls using the default. Makes procedure calls less susceptible to errors resulting from future changes.
5. Add missing "in" mode specifications to subprogram parameters. Makes procedure declarations more explicit and thus more understandable.
6. Adjust "in out" parameters when they are only set (to "out" mode) or only used (to "in mode") Makes parameters consistent with there actual use.
7. Move representation clauses immediately after the type they represent. Makes the software more readable; Required by Ada95.
8. Generate number declarations for literals in subprogram bodies and replace the literal with the named number. Makes procedure calls less susceptible to errors resulting from future changes.
9. Name loops that are nested. Makes software more readable and allows exit statements to be made explicit.
10. Name blocks that are nested. Makes software more readable.
11. Replace "or" and "and" operators with their short-circuit forms. Can make software more efficient.
12. Replace "when others" in case statements with actual values (enumeration only). Makes case statements less susceptible to errors resulting from future changes.
13. Replace literal ranges in case statements with actual values (enumeration only). Makes case statements less susceptible to errors resulting from future changes.
14. Replace "when others" in record aggregates when enumerated. Makes record aggregates less susceptible to errors resulting from future changes.
15. Replace "if then exit" with "exit when". Makes software more readable and reduces complexity.
16. Add explicit loop names to exit when possible. Makes software more readable and less susceptible to errors from future changes.
17. Qualify references that are not already fully qualified. Makes software more readable, more robust, and can lead to the removal of use clauses.
18. Add rename declarations for all infix operators used in a unit. Makes software more readable and can lead to the removal of use clauses.
19. Replace anonymous array type specifications with an explicit array type declaration. Makes the software more explicit and readable.
20. Generate explicit index types for array types when required. Makes software more readable and allows for use of attributes for lower-bound, upper-bound, and range values.
21. Replace "raise;" with explicit raise when possible. Makes software more readable and robust.
22. Replace aliased renames (that is, direct references to the renamed declaration when a rename is available) with the renamed name. Makes software more explicit and understandable.
23. Remove unused and redundant with clauses. Move with clauses from the spec to the body when possible. Reduces dependencies and complexity to minimal requirements. Can reduce recompilation time. Improves program structure.
24. Alphabetize context clauses. Makes location of specific with clauses easier.
25. Alphabetize rename clauses. Makes location of specific rename clauses easier.
26. Replace multi-name context clauses with a series of single-name context clauses. Makes the software more consistent and readable. Allows for better ordering.
27. Replace multi-name declarations with a series of single-name declarations. Makes the software more consistent and readable. Allows for separate default values.

The Update Process

Ada Repair will replace the current version of an Ada unit with one that no longer contains the requested coding violations. If necessary, Ada Repair will also check out controlled units before they are updated. It will also recompile and check in units after they have been updated when requested. Each unit specified for update will be traversed to locate all occurrences of the specified coding violations. By default an announcement of each required update is made in the log. An effort only option can be specified to announce the required changes but no make any actual updates to the software.

Managing Change

Since Ada Repair makes modifications to the files containing Ada units, it is important to ensure that the changes made are in fact desired changes. As users continue to use Ada Repair, they will gradually gain confidence that the updates are made correctly and are consistent with their coding standards. There are several safeguard methods to capture the updates that are made and allow one to revert to the previous version of a unit when the updates are not desired.

  1. All units should be placed under CMVC control. Before units are updated they should be checked-in to ensure that a baseline version is recorded. Ada Repair will then check the units out (when the Allow_Check_Out option is enabled), creating a new version with the updates. The differences between the two versions can then be displayed for inspection and acceptance. If the new version is unacceptable for some reason, the user can revert to the previous version or make manual changes to the new version to correct any problems. Alternatively, a user could not enable the Allow_Check_Out option, and then check out only those unit for which updates are desired. Differences could still be computed using the Control:Show:Differences operation.
  2. The old version of the unit can be explicitly saved in a new file called <ada_unit_name>.old when the Save_Old_Files option is selected. Alternatively, if the Replace_Existing_Units option is not selected then the new version of the unit will be saved in a file called <ada_unit_name>.new, leaving the old version untouched. Files can then be copied or deleted as desired to accept or reject the updates made by Ada Repair. This provides a manual method of version control that is automated with the CMVC approach in step 1.
  3. An Effort_Only option is available to list in the log all changes that would be made without actually making the updates to the ada files. This may be a prudent step before actual changes are requested.

Conflicting Updates

It is possible that two or more updates will attempt to modify the same span of code in an Ada unit. Ada Repair recognizes when updates would conflict with each other and makes only the first update. When conflicting updates are found, a notification in the log is made and the conflicting update is not made to the software. It is possible to run Ada Repair again in this case (after the new units are recompiled). The second execution will not have the original conflict and the update rejected during the first execution will be made.

Command-Line Interface repair_violations


-Use_Configuration = [string-expression, default = ""]

Option Descriptions:

The following options enable the updates specified in the list of updates on page 1.


ada repair | ada repair pdf (280K)

ada type interchange generator (ATIG) | ada analyzer | ada analyzer/ ada repair training

little tree home | about little tree | technical articles | email