TutorialComments




Prev | Up | Next | Back | Forward | Online Documentation Home Page

Comments

This chapter provides a summary of Ada-ASSURED's treatment of comments. We distinguish between comments that are automatically maintained in your source code by the style enforcer and comments that are authored by the user: End users can redefine Ada-ASSURED's built-in templates using the scripting language. An important use of this feature is to redefine Ada templates, e.g., procedure-body, to include templates for a project's standard header comments. This is described in:

Automatically Inserted Comments

Ada-ASSURED's style enforcer can create three sorts of comments in your source code that are maintained automatically by the ``behind the scene'' incremental analysis of your program: You should never have to explicitly delete an automatically generated comment—it goes away automatically when it is no longer relevant. The first two features are optional and can be suppressed; the third feature is not optional.

In-Line Diagnostic Messages

Ada-ASSURED maintains certain diagnostics incrementally during editing. Unlike a batch analysis tool that must be invoked periodically to update diagnostic output, Ada-ASSURED updates these messages immediately as the program is edited. Each message is formatted as a comment that begins with a distinctive prefix:

--ERROR-- [Enum] <text> Ada language error
--VIOLATION-- [Vnum] <text> Style enforcement violation
--INDICATOR-- [Inum] <text> Style enforcement indicator
Errors are illegal Ada constructs that will not compile. Violations are style defects. Typically, projects insist that all violations be repaired. Indicators are warnings of potential style problems that may or may not have to be repaired. For example,
X := 2#0001_0002#
       --ERROR-- [E21] All digits in the mantissa must be less than
       --ERROR-- the base.
       ;
Y := not (A or not (B and not C)) or C
       --VIOLATION-- [V19] Number of negative logic occurrences of
       --VIOLATION-- 3 exceeds maximum of 2.
       ;
Z := P / (Q / (R / (S / (T / (U / (V / W))))))
       --INDICATOR-- [I2] Expression nesting depth of 6 exceeds
       --INDICATOR-- maximum of 5.
       ;
The display of the three kinds of message is controlled by three enforcement parameters: where for each parameter there are four options: Taste and application will determine the settings of these parameters. A given file can be displayed in more than one window and view at a time. MESSAGES displays only the diagnostic comments but not Ada code. Thus, saving or printing a file in the MESSAGES view produces a diagnostic summary record. Clicking on a line in the MESSAGES view automatically scrolls a program window displaying the same file to the offending line in the Ada code. Clicking within [Enum], [Vnum], or [Inum] navigates to the appropriate page in the hypertext documentation system.

A complete list of all diagnostic messages together with their interpretation appears in Section Messages.

Inter-Unit Pagination

An inter-unit ``pagination comment'', as recommended by the SPC style guide, can be automatically inserted around packages, tasks, procedures, and functions. For example,

--~----------------------------------
package body P is
    --~-------------------------------
    procedure F is
    begin -- F
       <statement>
    end F;
    --~-------------------------------
end P;
--~----------------------------------
The length of the line is determined automatically. Note that the third character, a tilde ~, distinguishes pagination comments from a line of dashes that a user may insert. If enforcement parameter Pagination Marker Enforcement is off, no such comments are generated.

Comments that are contiguous with the beginning of the item are included within the pagination markers.

Name Echoing

Names of procedures, functions, packages, and tasks are echoed in a comment after the begin keyword of the unit. See Section Echoed names for further details.

User Comments

Ada-ASSURED supports several sorts of user comments described below. The different kinds of comments are identified by the first character after --. The choice of characters can be customized using Ada-ASSURED resources and enforcement parameters. The default choices are:

-- normal comment
--+ continuation comment
--| untouchable comment
--( begin freeform region
--) end freeform region
--C commented out code
None message comment

Left Comments and Right Comments

A program line that begins with a comment is called a left comment. For example:
-- This is a left comment.
-- This is another left comment.
Left comments are normally indented automatically according to the indentation level of their surrounding syntactic context. For example,
-- Step One.
if X = 0 then
    -- swap A and B.
    T := A;
    A := B;
    B := T;
end if;
A comment that appears on a line to the right of another Ada construct is called a right comment. For example:
X := 0;       -- This is a right comment.
Y := Z + 1;   -- This is another right comment.
Right comments are normally aligned some distance to the right of the Ada code they comment, as shown above. Right comments following long lines of Ada follow the Ada immediately.

Continuation Comments

A common standard requires that no line be longer than a given number of characters, say 80. Typically, long commentary is split into multiple comments so that each part fits within the bound. For example:
-- This is a long comment that has been split
-- into two comments so no line is too long.
Put("Hello World");
If this code fragment is moved to a more deeply nested region of the program, Ada-ASSURED automatically word wraps the comment lines so they conform to the maximal line-length standard:
...
    begin
          -- This is a long comment that has
          --+ been split
          -- into two comments so no line is
          --+ too long.
          Put("Hello World");
    end
...
The continuation lines of a word wrapped comment, which are called continuation comments, each begin with --+. The character used to signify continuation comments (+) can be customized using Ada-ASSURED resource user2 (See Setting Resources).

The above example illustrates that each comment is wrapped individually. This is similar to the wrapping of text in a word processor where each paragraph is wrapped individually. Without knowing whether successive comments are related, this is as good a job as we can do. However, suppose the second line of the original commentary had been entered as a continuation comment:

-- This is a long comment that has been split
--+ into two comments so no line is too long.
Put("Hello World");
Then, when the code fragment is moved, the entire commentary is rewrapped automatically:
...
    begin
          -- This is a long comment that has
          --+ been split into two comments
          --+ so no line is too long.
          Put("Hello World");
    end
...
To take full advantage of the automatic rewrapping of comments, enter long comments as follows: To convert a sequence of existing -- comments into a single -- comment followed by whatever --+ continuation comments are needed, just drag out the sequence of comments and invoke the merge-comment transform. Comments that contain tabular or boxed information should not be merged into a sequence of continuation comments.

Old code that has been manually formatted may contain comments that are not indented according to the structure of the Ada. For example,

if B then
---------------------------------------
-- This is the really important case --
---------------------------------------
    X := 0;
end if;
When Ada-ASSURED indents such comments according to the structure of the surrounding Ada, lines that are too long will be wrapped. This can present problems when such comments are tabular or boxed. In particular, For example,
if B then
    ---------------------------------------
    -- This is the really important
       --+ case --
    ---------------------------------------
    X := 0;
end if;
Such comments must be touched up. It is best to edit the text so it fits on the lines when properly indented. However, if this is not possible, you may wish to use one of the special forms of comment that are immune to the automatic indentation rules:

Untouchable Comments

The horizontal alignment of a comment that begins with any of the characters in Ada-ASSURED resource untouchableComments (see Setting Resources) is never changed by the formatter. In particular, The default value for untouchableComments is the character `|'. Thus, the example above can be touched up as:
if B then
--|-----------------------------------
--| This is the really important case
--|-----------------------------------
    X := 0;
end if;

Column-One Comments

If Ada-ASSURED resource columnOneComments is True (see Setting Resources), all comments that begin in column one are treated specially. In particular:

A comment entered interactively at an indented placeholder is, by definition, a column-one comment if the -- occurs as the first two characters typed. Such a comment is repositioned to column one by the formatter immediately after syntactic analysis.

Freeform text

Certain regions of text can be marked as freeform. Within these regions, any text may appear, even illegal Ada code. This can be used to exempt regions of code from processing by the formatter.

The region of freeform text is bracketed by distinctive comments, e.g., --( and --), that must each appear on their own lines. For example:

--(
    A := 0; B := 0; C := 0;
--)
is a freeform text region. The special characters used in the comments at the begin and end of a freeform region are customizable, and are specified by string-valued Ada-ASSURED resources freeformTextBegin and freeformTextEnd (see Setting Resources).

The Ada-ASSURED resource parseFreeformText controls whether an attempt should be made to parse the freeform text. If it is True, the text will be parsed, and if there is a syntax error, an error message will be printed before the text. For example:

--ERROR-- Freeform text contains syntax error.
--(
    this is freeform text
--)
If the text parses correctly, it is subject to analysis and any violations and indicators appear in the MESSAGES view. Note that violation and indicator messages do not appear in-line in freeform text.

The enforcement parameter Freeform Text Enforcement controls whether an occurrence of freeform text should be considered to be a violation. If on, the following message will appear for each occurrence of freeform text:

--VIOLATION-- Freeform text is not allowed.

Message Comments

An Ada comment that is always displayed in the MESSAGES view is called a message comment. The format of message comments is controlled by the enforcement parameter Message Comments. This parameter is a string and any comment that begins with --c, where c is in the string, is considered a message comment. The default value for this parameter is the empty string, but for the examples below assume the value is M.

One use for message comments is to annotate the style diagnostic report with explanations or excuses. For example, suppose a particular use of goto is authorized, but goto statements, in general, are considered violations. Then a message comment can be used to record the authorization. For example, suppose violations are displayed in the MESSAGES view, but not inline. Then the Ada file segment

--M Style waiver W13457. Authorized by John Doe, 4/1/94.
goto L;
would appear in the MESSAGES view as:
--M Style waiver W13457. Authorized by John Doe, 4/1/94.
--VIOLATION-- Use of GOTO is not allowed.

A second use for message comments is bookmarks. As with any line in the MESSAGES view, clicking on a bookmark scrolls to the corresponding location in the Ada code. Bookmarks placed (temporarily) at the locations of current interest facilitate rapid context switches among those locations.

Commented-out Code

The text of a normal comment is uninterpreted. When such text is Ada code, it is immune to the formatting and standardization rules of the style guide. A special form of comment is provided for text that is Ada code. Except for the fact that each line of such text is preceded by a distinctive comment string, e.g., --C, it is analyzed, formatted, and style checked like any other Ada code. For example:
A := 0; 
-- On platform 007, initialize as follows: 
--C A := 2#0001_0002#
--C       --ERROR-- [E21] All digits in the mantissa 
--C       --ERROR--   must be less than the base.
--C       ;
B := 0;
The character that indicates a ``comment-out'' comment is customizable, and is specified by string-valued Ada-ASSURED resource commentOutString (see Setting Resources).

One use for such comments is for an Ada-based design. The Ada constructs are tested for syntactic correctness and are formatted automatically according to the Ada style guide, yet the text all appears to the right of --C's.

The transform comment-out can be used to embed an arbitrary group of compilation units or statements inside this special form of comment. The transform uncomment-out reverses the process.

Automatic Movement of Comments

The rules of Ada permit a comment to appear between any two tokens. Ada-ASSURED restricts the positions of comments according to its style rules. When a file is opened that was created using another editor, comments may be encountered at locations where they are not permitted by Ada-ASSURED. Such comments will never be discarded, but may be moved to either:

For example, if a comment appears within an expression:
Area := (22 / 7) -- approximation to pi
              * R ** 2;
then it will be moved. The result will be:
Area := 22 / 7 * R ** 2;
-- approximation to pi

Marker Comments

Comments after end if, end case, and else are called marker comments. The SPC style guide suggests the use of marker comments for long or deeply nested if and case statements. Enforcement parameters can be set to require the use of marker comments depending on either the lines of code or the nesting depth of an if or case.

Header Comments

The templates built into Ada-ASSURED can be customized and extended to support project-specific headers, i.e., comments that document a file or construct in a standard format. For example, the built-in transform procedure-body just inserts the generic Ada code template:

--~--------------------------------------------------------------

procedure <identifier> is

    <basic_declarative_item>

begin
    <statement>
end ;

--~--------------------------------------------------------------
But the transform can be redefined so that it includes prompts for a project's standard procedure header as well. For example:
--~--------------------------------------------------------------

procedure <identifier> is

    --------------------------------------------------------
    --# CSU
    --
    --# extract error_handling
    --# <Describe any error handling here.>
    --# end
    --------------------------------------------------------

    <basic_declarative_item>

begin
    --| PDL begins here
    --| PDL ends here
    <statement>
end ;

--~--------------------------------------------------------------

Ada-ASSURED is distributed with several sample header libraries that illustrate how to define your own:

Command eval-file can be used to load one (or both) of these libraries. Thereafter, the redefinition of headers can be enabled or disabled by invoking the appropriate command from the Options menu. The headers are initially disabled. Section User-defined Headers contains further information on header libraries.


Forward