The -gnatyx switch causes the compiler to enforce specified style rules. A limited set of style rules has been used in writing the GNAT sources themselves. This switch allows user programs to activate all or some of these checks. If the source program fails a specified style check, an appropriate message is given, preceded by the character sequence “(style)”. This message does not prevent successful compilation (unless the -gnatwe switch is used).
Note that this is by no means intended to be a general facility for checking arbitrary coding standards. It is simply an embedding of the style rules we have chosen for the GNAT sources. If you are starting a project which does not have established style standards, you may find it useful to adopt the entire set of GNAT coding standards, or some subset of them.
The string x is a sequence of letters or digits indicating the particular style checks to be performed. The following checks are defined:
--
starting on a column that is a multiple of
the alignment level, or they may be aligned the same way as the following
non-blank line (this is useful when full line comments appear in the middle
of a statement, or they may be aligned with the source line on the previous
non-blank line.
digits
used as attributes names, must be written in mixed case, that is, the
initial letter and any letter following an underscore must be uppercase.
All other letters must be lowercase.
and then
/or else
are
required.
--
” that starts the column must either start in column one,
or else at least one blank must precede this sequence.
--
” at the start of the comment.
--
” that starts the comment, with the following exceptions.
--
” characters, possibly preceded
by blanks is permitted.
--x
” where x
is a special character
is permitted.
This allows proper processing of the output generated by specialized tools
including gnatprep (where “--!
” is used) and the SPARK
annotation
language (where “--#
” is used). For the purposes of this rule, a
special character is defined as being in one of the ASCII ranges
16#21#...16#2F#
or 16#3A#...16#3F#
.
Note that this usage is not permitted
in GNAT implementation units (i.e., when -gnatg is used).
--
” is permitted as long as at
least one blank follows the initial “--
”. Together with the preceding
rule, this allows the construction of box comments, as shown in the following
example:
--------------------------- -- This is a box comment -- -- with two text lines. -- ---------------------------
c
except that only one space
is required following the --
of a comment instead of two.
end
statements ending subprograms and on
exit
statements exiting named loops, are required to be present.
then
must appear either on the same
line as corresponding if
, or on a line on its own, lined
up under the if
.
in
(the default mode) is not
allowed to be given explicitly. in out
is fine,
but not in
on its own.
digits
used as attribute names to which this check
does not apply).
else
keyword must
be lined up with the corresponding if
keyword.
There are two respects in which the style rule enforced by this check
option are more liberal than those in the Ada Reference Manual. First
in the case of record declarations, it is permissible to put the
record
keyword on the same line as the type
keyword, and
then the end
in end record
must line up under type
.
This is also permitted when the type declaration is split on two lines.
For example, any of the following three layouts is acceptable:
type q is record a : integer; b : integer; end record; type q is record a : integer; b : integer; end record; type q is record a : integer; b : integer; end record; |
Second, in the case of a block statement, a permitted alternative
is to put the block label on the same line as the declare
or
begin
keyword, and then line the end
keyword up under
the block label. For example both the following are permitted:
Block : declare A : Integer := 3; begin Proc (A, A); end Block; Block : declare A : Integer := 3; begin Proc (A, A); end Block; |
The same alternative format is allowed for loops. For example, both of the following are permitted:
Clear : while J < 10 loop A (J) := 0; end loop Clear; Clear : while J < 10 loop A (J) := 0; end loop Clear; |
Integer
and ASCII.NUL
).
then
/else
.
No statements are allowed
on the same line as a then
or else
keyword following the
keyword in an if
statement. or else
and and then
are not
affected, and a special exception allows a pragma to appear after else
.
abs
and not
must be followed by a space.
=>
must be surrounded by spaces.
<>
must be preceded by a space or a left parenthesis.
**
must be surrounded by spaces.
There is no restriction on the layout of the **
binary operator.
not
token and a following in
token.
if
statements, while
statements and
exit
statements.
gnaty3aAbcefhiklmnprst
, that is all checking
options enabled with the exception of -gnatyB, -gnatyd,
-gnatyI, -gnatyLnnn, -gnatyo, -gnatyO,
-gnatyS, -gnatyu, and -gnatyx.
In the above rules, appearing in column one is always permitted, that is, counts as meeting either a requirement for a required preceding space, or as meeting a requirement for no preceding space.
Appearing at the end of a line is also always permitted, that is, counts as meeting either a requirement for a following space, or as meeting a requirement for no following space.
If any of these style rules is violated, a message is generated giving
details on the violation. The initial characters of such messages are
always “(style)
”. Note that these messages are treated as warning
messages, so they normally do not prevent the generation of an object
file. The -gnatwe switch can be used to treat warning messages,
including style messages, as fatal errors.
The switch -gnaty on its own (that is not followed by any letters or digits) is equivalent to the use of -gnatyy as described above, that is all built-in standard style check options are enabled.
The switch -gnatyN clears any previously set style checks.