OSDN Git Service

PR bootstrap/56258
[pf3gnuchains/gcc-fork.git] / gcc / ada / gnat-style.texi
1 \input texinfo   @c -*-texinfo-*-
2 @c %**start of header
3
4 @c oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
5 @c                                                                            o
6 @c                           GNAT DOCUMENTATION                               o
7 @c                                                                            o
8 @c                     G N A T   C O D I N G   S T Y L E                      o
9 @c                                                                            o
10 @c   GNAT is maintained by Ada Core Technologies Inc (http://www.gnat.com).   o
11 @c                                                                            o
12 @c oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
13
14 @setfilename gnat-style.info
15
16 @copying
17 Copyright @copyright{} 1992-2008, Free Software Foundation, Inc.
18
19 Permission is granted to copy, distribute and/or modify this document
20 under the terms of the GNU Free Documentation License, Version 1.3 or
21 any later version published by the Free Software Foundation; with no
22 Invariant Sections, with no Front-Cover Texts and with no Back-Cover
23 Texts.  A copy of the license is included in the section entitled
24 ``GNU Free Documentation License''.
25 @end copying
26
27 @settitle GNAT Coding Style
28 @setchapternewpage odd
29
30 @include gcc-common.texi
31
32 @dircategory Software development
33 @direntry
34 * gnat-style: (gnat-style).      GNAT Coding Style
35 @end direntry
36
37 @macro syntax{element}
38 @t{\element\}
39 @end macro
40 @c %**end of header
41
42 @titlepage
43 @titlefont{GNAT Coding Style:}
44 @sp 1
45 @title A Guide for GNAT Developers
46 @subtitle GNAT, The GNU Ada Compiler
47 @versionsubtitle
48 @author Ada Core Technologies, Inc.
49 @page
50 @vskip 0pt plus 1filll
51
52 @insertcopying
53 @end titlepage
54
55 @raisesections
56
57 @node    Top,       General,         , (dir)
58 @comment node-name, next,    previous, up
59
60 @ifnottex
61 @noindent
62 GNAT Coding Style@*
63 A Guide for GNAT Developers
64 @sp 2
65 @noindent
66 GNAT, The GNU Ada Compiler@*
67
68 @noindent
69 @insertcopying
70 @end ifnottex
71
72
73 @menu
74 * General::
75 * Lexical Elements::
76 * Declarations and Types::
77 * Expressions and Names::
78 * Statements::
79 * Subprograms::
80 * Packages::
81 * Program Structure::
82 * GNU Free Documentation License::
83 * Index::
84 @end menu
85
86 @c  -------------------------------------------------------------------------
87 @node    General, Lexical Elements, Top, Top
88 @section General
89 @c  -------------------------------------------------------------------------
90
91 @noindent
92 Most of GNAT is written in Ada using a consistent style to ensure
93 readability of the code.  This document has been written to help
94 maintain this consistent style, while having a large group of developers
95 work on the compiler.
96
97 For the coding style in the C parts of the compiler and run time,
98 see the GNU Coding Guidelines.
99
100 This document is structured after the @cite{Ada Reference Manual}.
101 Those familiar with that document should be able to quickly
102 lookup style rules for particular constructs.
103
104
105 @c  -------------------------------------------------------------------------
106 @node    Lexical Elements, Declarations and Types, General, Top
107 @section Lexical Elements
108 @c  -------------------------------------------------------------------------
109 @cindex Lexical elements
110
111 @subsection Character Set and Separators
112 @c  -------------------------------------------------------------------------
113 @cindex Character set
114 @cindex ASCII
115 @cindex Separators
116 @cindex End-of-line
117 @cindex Line length
118 @cindex Indentation
119
120 @itemize @bullet
121 @item
122 The character set used should be plain 7-bit ASCII@.
123 The only separators allowed are space and the end-of-line sequence.
124 No other control character or format effector (such as @code{HT},
125 @code{VT}, @code{FF})
126 should be used.
127 The normal end-of-line sequence is used, which may be
128 @code{LF}, @code{CR/LF} or @code{CR},
129 depending on the host system.  An optional @code{SUB}
130 (@code{16#1A#}) may be present as the
131 last character in the file on hosts using that character as file terminator.
132
133 @item
134 Files that are checked in or distributed should be in host format.
135
136 @item
137 A line should never be longer than 79 characters, not counting the line
138 separator.
139
140 @item
141 Lines must not have trailing blanks.
142
143 @item
144 Indentation is 3 characters per level for @code{if} statements, loops, and
145 @code{case} statements.
146 For exact information on required spacing between lexical
147 elements, see file @file{style.adb}.
148 @cindex @file{style.adb} file
149 @end itemize
150
151
152 @subsection Identifiers
153 @c  -------------------------------------------------------------------------
154 @itemize @bullet
155 @cindex Identifiers
156
157 @item
158 Identifiers will start with an upper case letter, and each letter following
159 an underscore will be upper case.
160 @cindex Casing (for identifiers)
161 Short acronyms may be all upper case.
162 All other letters are lower case.
163 An exception is for identifiers matching a foreign language.  In particular,
164 we use all lower case where appropriate for C@.
165
166 @item
167 Use underscores to separate words in an identifier.
168 @cindex Underscores
169
170 @item Try to limit your use of abbreviations in identifiers.
171 It is ok to make a few abbreviations, explain what they mean, and then
172 use them frequently, but don't use lots of obscure abbreviations.  An
173 example is the @code{ALI} word which stands for Ada Library
174 Information and is by convention always written in upper-case when
175 used in entity names.
176
177 @smallexample @c adanocomment
178        procedure Find_ALI_Files;
179 @end smallexample
180
181 @item
182 Don't use the variable name @code{I}, use @code{J} instead; @code{I} is too
183 easily confused with @code{1} in some fonts.  Similarly don't use the
184 variable @code{O}, which is too easily mistaken for the number @code{0}.
185 @end itemize
186
187 @subsection Numeric Literals
188 @c  -------------------------------------------------------------------------
189 @cindex Numeric literals
190
191 @itemize @bullet
192 @item
193 Numeric literals should include underscores where helpful for
194 readability.
195 @cindex Underscores
196
197 @smallexample
198       1_000_000
199       16#8000_0000#
200       3.14159_26535_89793_23846
201 @end smallexample
202 @end itemize
203
204 @subsection Reserved Words
205 @c  -------------------------------------------------------------------------
206 @cindex Reserved words
207
208 @itemize @bullet
209 @item
210 Reserved words use all lower case.
211 @cindex Casing (for reserved words)
212
213 @smallexample @c adanocomment
214        return else
215 @end smallexample
216
217 @item
218 The words @code{Access}, @code{Delta} and @code{Digits} are
219 capitalized when used as @syntax{attribute_designator}.
220 @end itemize
221
222 @subsection Comments
223 @c  -------------------------------------------------------------------------
224 @cindex Comments
225
226 @itemize @bullet
227 @item
228 A comment starts with @code{--} followed by two spaces.
229 The only exception to this rule (i.e.@: one space is tolerated) is when the
230 comment ends with a single space followed by @code{--}.
231 It is also acceptable to have only one space between @code{--} and the start
232 of the comment when the comment is at the end of a line,
233 after some Ada code.
234
235 @item
236 Every sentence in a comment should start with an upper-case letter (including
237 the first letter of the comment).
238 @cindex Casing (in comments)
239
240 @item
241 When declarations are commented with ``hanging'' comments, i.e.@:
242 comments after the declaration, there is no blank line before the
243 comment, and if it is absolutely necessary to have blank lines within
244 the comments, e.g. to make paragraph separations within a single comment,
245 these blank lines @emph{do} have a @code{--} (unlike the
246 normal rule, which is to use entirely blank lines for separating
247 comment paragraphs).  The comment starts at same level of indentation
248 as code it is commenting.
249 @cindex Blank lines (in comments)
250 @cindex Indentation
251
252 @smallexample @c adanocomment
253        z : Integer;
254        --  Integer value for storing value of z
255        --
256        --  The previous line was a blank line.
257 @end smallexample
258
259 @item
260 Comments that are dubious or incomplete, or that comment on possibly
261 wrong or incomplete code, should be preceded or followed by @code{???}@.
262
263 @item
264 Comments in a subprogram body must generally be surrounded by blank lines.
265 An exception is a comment that follows a line containing a single keyword
266 (@code{begin}, @code{else}, @code{loop}):
267
268 @smallexample @c adanocomment
269 @group
270        begin
271           --  Comment for the next statement
272
273           A := 5;
274
275           --  Comment for the B statement
276
277           B := 6;
278        end;
279 @end group
280 @end smallexample
281
282 @item
283 In sequences of statements, comments at the end of the lines should be
284 aligned.
285 @cindex Alignment (in comments)
286
287 @smallexample @c adanocomment
288         My_Identifier := 5;      --  First comment
289         Other_Id := 6;           --  Second comment
290 @end smallexample
291
292 @item
293 Short comments that fit on a single line are @emph{not} ended with a
294 period.  Comments taking more than a line are punctuated in the normal
295 manner.
296
297 @item
298 Comments should focus on @emph{why} instead of @emph{what}.
299 Descriptions of what subprograms do go with the specification.
300
301 @item
302 Comments describing a subprogram spec should specifically mention the
303 formal argument names.  General rule: write a comment that does not
304 depend on the names of things.  The names are supplementary, not
305 sufficient, as comments.
306
307 @item
308 @emph{Do not} put two spaces after periods in comments.
309 @end itemize
310
311 @c  -------------------------------------------------------------------------
312 @node    Declarations and Types, Expressions and Names, Lexical Elements,Top
313 @section Declarations and Types
314 @c  -------------------------------------------------------------------------
315 @cindex Declarations and Types
316
317 @itemize @bullet
318 @item
319 In entity declarations, colons must be surrounded by spaces.  Colons
320 should be aligned.
321 @cindex Alignment (in declarations)
322
323 @smallexample @c adanocomment
324         Entity1   : Integer;
325         My_Entity : Integer;
326 @end smallexample
327
328 @item
329 Declarations should be grouped in a logical order.
330 Related groups of declarations may be preceded by a header comment.
331
332 @item
333 All local subprograms in a subprogram or package body should be declared
334 before the first local subprogram body.
335
336 @item
337 Do not declare local entities that hide global entities.
338 @cindex Hiding of outer entities
339
340 @item
341 Do not declare multiple variables in one declaration that spans lines.
342 Start a new declaration on each line, instead.
343
344 @item
345 The @syntax{defining_identifier}s of global declarations serve as
346 comments of a sort.  So don't choose terse names, but look for names
347 that give useful information instead.
348
349 @item
350 Local names can be shorter, because they are used only within
351 one context, where comments explain their purpose.
352
353 @end itemize
354
355
356 @c  -------------------------------------------------------------------------
357 @node    Expressions and Names, Statements, Declarations and Types, Top
358 @section Expressions and Names
359 @c  -------------------------------------------------------------------------
360 @cindex Expressions and names
361
362 @itemize @bullet
363
364 @item
365 Every operator must be surrounded by spaces. An exception is that
366 this rule does not apply to the exponentiation operator, for which
367 there are no specific layout rules. The reason for this exception
368 is that sometimes it makes clearer reading to leave out the spaces
369 around exponentiation.
370 @cindex Operators
371
372 @smallexample @c adanocomment
373        E := A * B**2 + 3 * (C - D);
374 @end smallexample
375
376 @item
377 Use parentheses where they clarify the intended association of operands
378 with operators:
379 @cindex Parenthesization of expressions
380 @smallexample @c adanocomment
381        (A / B) * C
382 @end smallexample
383 @end itemize
384
385 @c  -------------------------------------------------------------------------
386 @node    Statements, Subprograms, Expressions and Names, Top
387 @section Statements
388 @c  -------------------------------------------------------------------------
389 @cindex Statements
390
391 @subsection Simple and Compound Statements
392 @c  -------------------------------------------------------------------------
393 @cindex Simple and compound statements
394
395 @itemize @bullet
396 @item
397 Use only one statement or label per line.
398 @item
399 A longer @syntax{sequence_of_statements} may be divided in logical
400 groups or separated from surrounding code using a blank line.
401 @end itemize
402
403 @subsection If Statements
404 @c  -------------------------------------------------------------------------
405 @cindex @code{if} statement
406
407 @itemize @bullet
408 @item
409 When the @code{if}, @code{elsif} or @code{else} keywords fit on the
410 same line with the condition and the @code{then} keyword, then the
411 statement is formatted as follows:
412 @cindex Alignment (in an @code{if} statement)
413
414 @smallexample @c adanocomment
415 @group
416         if @var{condition} then
417            ...
418         elsif @var{condition} then
419            ...
420         else
421            ...
422         end if;
423 @end group
424 @end smallexample
425
426 @noindent
427 When the above layout is not possible, @code{then} should be aligned
428 with @code{if}, and conditions should preferably be split before an
429 @code{and} or @code{or} keyword a follows:
430
431 @smallexample @c adanocomment
432 @group
433         if @var{long_condition_that_has_to_be_split}
434           and then @var{continued_on_the_next_line}
435         then
436            ...
437         end if;
438 @end group
439 @end smallexample
440
441 @noindent
442 The @code{elsif}, @code{else} and @code{end if} always line up with
443 the @code{if} keyword.  The preferred location for splitting the line
444 is before @code{and} or @code{or}.  The continuation of a condition is
445 indented with two spaces or as many as needed to make nesting clear.
446 As an exception, if conditions are closely related either of the
447 following is allowed:
448
449 @smallexample
450 @group
451      if x = lakdsjfhlkashfdlkflkdsalkhfsalkdhflkjdsahf
452           or else
453         x = asldkjhalkdsjfhhfd
454           or else
455         x = asdfadsfadsf
456      then
457        ...
458      end if;
459 @end group
460
461 @group
462      if x = lakdsjfhlkashfdlkflkdsalkhfsalkdhflkjdsahf or else
463         x = asldkjhalkdsjfhhfd                         or else
464         x = asdfadsfadsf
465      then
466        ...
467      end if;
468 @end group
469 @end smallexample
470
471 @item
472 Conditions should use short-circuit forms (@code{and then},
473 @code{or else}), except when the operands are boolean variables
474 or boolean constants.
475 @cindex Short-circuit forms
476
477 @item
478 Complex conditions in @code{if} statements are indented two characters:
479 @cindex Indentation (in @code{if} statements)
480
481 @smallexample @c adanocomment
482 @group
483       if @var{this_complex_condition}
484         and then @var{that_other_one}
485         and then @var{one_last_one}
486       then
487          ...
488       end if;
489 @end group
490 @end smallexample
491
492 @noindent
493 There are some cases where complex conditionals can be laid out
494 in manners that do not follow these rules to preserve better
495 parallelism between branches, e.g.
496
497 @smallexample @c adanocomment
498 @group
499       if xyz.abc (gef) = 'c'
500            or else
501          xyz.abc (gef) = 'x'
502       then
503          ...
504       end if;
505 @end group
506 @end smallexample
507
508
509 @item
510 Every @code{if} block is preceded and followed by a blank line, except
511 where it begins or ends a @syntax{sequence_of_statements}.
512 @cindex Blank lines (in an @code{if} statement)
513
514 @smallexample @c adanocomment
515 @group
516         A := 5;
517
518         if A = 5 then
519            null;
520         end if;
521
522         A := 6;
523 @end group
524 @end smallexample
525 @end itemize
526
527 @subsection Case Statements
528 @cindex @code{case} statements
529
530 @itemize @bullet
531 @item
532 Layout is as below.  For long @code{case} statements, the extra indentation
533 can be saved by aligning the @code{when} clauses with the opening @code{case}.
534
535 @smallexample @c adanocomment
536 @group
537        case @var{expression} is
538           when @var{condition} =>
539              ...
540           when @var{condition} =>
541              ...
542        end case;
543 @end group
544 @end smallexample
545 @end itemize
546
547 @subsection Loop Statements
548 @cindex Loop statements
549
550 @itemize @bullet
551 @noindent
552 When possible, have @code{for} or @code{while} on one line with the
553 condition and the @code{loop} keyword.
554
555 @smallexample @c adanocomment
556 @group
557        for J in S'Range loop
558           ...
559        end loop;
560 @end group
561 @end smallexample
562
563 @noindent
564 If the condition is too long, split the condition (see ``If
565 statements'' above) and align @code{loop} with the @code{for} or
566 @code{while} keyword.
567 @cindex Alignment (in a loop statement)
568
569 @smallexample @c adanocomment
570 @group
571       while @var{long_condition_that_has_to_be_split}
572         and then @var{continued_on_the_next_line}
573       loop
574          ...
575       end loop;
576 @end group
577 @end smallexample
578
579 @noindent
580 If the @syntax{loop_statement} has an identifier, it is laid out as follows:
581
582 @smallexample @c adanocomment
583 @group
584       Outer : while not @var{condition} loop
585          ...
586       end Outer;
587 @end group
588 @end smallexample
589 @end itemize
590
591 @subsection Block Statements
592 @cindex Block statement
593
594 @itemize @bullet
595 @item
596 The @code{declare} (optional), @code{begin} and @code{end} words
597 are aligned, except when the @syntax{block_statement} is named.  There
598 is a blank line before the @code{begin} keyword:
599 @cindex Alignment (in a block statement)
600
601 @smallexample @c adanocomment
602 @group
603       Some_Block : declare
604          ...
605
606       begin
607          ...
608       end Some_Block;
609 @end group
610 @end smallexample
611
612 @end itemize
613
614 @c  -------------------------------------------------------------------------
615 @node    Subprograms, Packages, Statements, Top
616 @section Subprograms
617 @c  -------------------------------------------------------------------------
618 @cindex Subprograms
619
620 @subsection Subprogram Declarations
621 @c  -------------------------------------------------------------------------
622 @itemize @bullet
623
624 @item
625 Do not write the @code{in} for parameters.
626
627 @smallexample @c adanocomment
628       function Length (S : String) return Integer;
629 @end smallexample
630
631 @item
632 When the declaration line for a procedure or a function is too long to fit
633 the entire declaration (including the keyword procedure or function) on a
634 single line, then fold it, putting a single parameter on a line, aligning
635 the colons, as in:
636
637 @smallexample @c adanocomment
638 @group
639      procedure Set_Heading
640        (Source : String;
641         Count  : Natural;
642         Pad    : Character := Space;
643         Fill   : Boolean   := True);
644 @end group
645 @end smallexample
646
647 @noindent
648 In the case of a function, if the entire spec does not fit on one line, then
649 the return may appear after the last parameter, as in:
650
651 @smallexample @c adanocomment
652 @group
653       function Head
654         (Source : String;
655          Count  : Natural;
656          Pad    : Character := Space) return String;
657 @end group
658 @end smallexample
659
660 @noindent
661 Or it may appear on its own as a separate line. This form is preferred when
662 putting the return on the same line as the last parameter would result in
663 an overlong line. The return type may optionally be aligned with the types
664 of the parameters (usually we do this aligning if it results only in a small
665 number of extra spaces, and otherwise we don't attempt to align). So two
666 alternative forms for the above spec are:
667
668 @smallexample @c adanocomment
669 @group
670       function Head
671         (Source : String;
672          Count  : Natural;
673          Pad    : Character := Space)
674          return   String;
675
676       function Head
677         (Source : String;
678          Count  : Natural;
679          Pad    : Character := Space)
680          return String;
681 @end group
682 @end smallexample
683
684 @end itemize
685
686 @subsection Subprogram Bodies
687 @c  -------------------------------------------------------------------------
688 @cindex Subprogram bodies
689
690 @itemize @bullet
691 @item
692 Function and procedure bodies should usually be sorted alphabetically. Do
693 not attempt to sort them in some logical order by functionality. For a
694 sequence of subprogram specs, a general alphabetical sorting is also
695 usually appropriate, but occasionally it makes sense to group by major
696 function, with appropriate headers.
697
698 @item
699 All subprograms have a header giving the function name, with the following
700 format:
701
702 @smallexample @c adanocomment
703 @group
704       -----------------
705       -- My_Function --
706       -----------------
707
708       procedure My_Function is
709       begin
710         ...
711       end My_Function;
712 @end group
713 @end smallexample
714
715 @noindent
716 Note that the name in the header is preceded by a single space,
717 not two spaces as for other comments. These headers are used on
718 nested subprograms as well as outer level subprograms. They may
719 also be used as headers for sections of comments, or collections
720 of declarations that are related.
721
722 @item
723 Every subprogram body must have a preceding @syntax{subprogram_declaration}.
724
725 @item
726 @cindex Blank lines (in subprogram bodies)
727 A sequence of declarations may optionally be separated from the following
728 begin by a blank line.  Just as we optionally allow blank lines in general
729 between declarations, this blank line should be present only if it improves
730 readability. Generally we avoid this blank line if the declarative part is
731 small (one or two lines) and the body has no blank lines, and we include it
732 if the declarative part is long or if the body has blank lines.
733
734 @item
735 If the declarations in a subprogram contain at least one nested
736 subprogram body, then just before the @code{begin} of the enclosing
737 subprogram, there is a comment line and a blank line:
738
739 @smallexample @c adanocomment
740 @group
741     --  Start of processing for @var{Enclosing_Subprogram}
742
743     begin
744       ...
745     end @var{Enclosing_Subprogram};
746 @end group
747 @end smallexample
748
749 @item
750 When nested subprograms are present, variables that are referenced by any
751 nested subprogram should precede the nested subprogram specs. For variables
752 that are not referenced by nested procedures, the declarations can either also
753 be before any of the nested subprogram specs (this is the old style, more
754 generally used). Or then can come just before the begin, with a header. The
755 following example shows the two possible styles:
756
757 @smallexample @c adanocomment
758 @group
759     procedure Style1 is
760        Var_Referenced_In_Nested      : Integer;
761        Var_Referenced_Only_In_Style1 : Integer;
762
763        proc Nested;
764        --  Comments ...
765
766
767        ------------
768        -- Nested --
769        ------------
770
771        procedure Nested is
772        begin
773           ...
774        end Nested;
775
776     --  Start of processing for Style1
777
778     begin
779        ...
780     end Style1;
781
782 @end group
783
784 @group
785     procedure Style2 is
786        Var_Referenced_In_Nested : Integer;
787
788        proc Nested;
789        --  Comments ...
790
791        ------------
792        -- Nested --
793        ------------
794
795        procedure Nested is
796        begin
797           ...
798        end Nested;
799
800        --  Local variables
801
802        Var_Referenced_Only_In_Style2 : Integer;
803
804     --  Start of processing for Style2
805
806     begin
807        ...
808     end Style2;
809
810 @end group
811 @end smallexample
812
813 @noindent
814 For new code, we generally prefer Style2, but we do not insist on
815 modifying all legacy occurrences of Style1, which is still much
816 more common in the sources.
817
818 @end itemize
819
820
821 @c  -------------------------------------------------------------------------
822 @node    Packages, Program Structure, Subprograms, Top
823 @section Packages and Visibility Rules
824 @c  -------------------------------------------------------------------------
825 @cindex Packages
826
827 @itemize @bullet
828 @item
829 All program units and subprograms have their name at the end:
830
831 @smallexample @c adanocomment
832 @group
833       package P is
834          ...
835       end P;
836 @end group
837 @end smallexample
838
839 @item
840 We will use the style of @code{use}-ing @code{with}-ed packages, with
841 the context clauses looking like:
842 @cindex @code{use} clauses
843
844 @smallexample @c adanocomment
845 @group
846       with A; use A;
847       with B; use B;
848 @end group
849 @end smallexample
850
851 @item
852 Names declared in the visible part of packages should be
853 unique, to prevent name clashes when the packages are @code{use}d.
854 @cindex Name clash avoidance
855
856 @smallexample @c adanocomment
857 @group
858       package Entity is
859          type Entity_Kind is ...;
860          ...
861       end Entity;
862 @end group
863 @end smallexample
864
865 @item
866 After the file header comment, the context clause and unit specification
867 should be the first thing in a @syntax{program_unit}.
868
869 @item
870 Preelaborate, Pure and Elaborate_Body pragmas should be added right after the
871 package name, indented an extra level and using the parameterless form:
872
873 @smallexample @c adanocomment
874 @group
875       package Preelaborate_Package is
876          pragma Preelaborate;
877          ...
878       end Preelaborate_Package;
879 @end group
880 @end smallexample
881
882 @end itemize
883
884 @c  -------------------------------------------------------------------------
885 @node    Program Structure, GNU Free Documentation License, Packages, Top
886 @section Program Structure and Compilation Issues
887 @c  -------------------------------------------------------------------------
888 @cindex Program structure
889
890 @itemize @bullet
891 @item
892 Every GNAT source file must be compiled with the @option{-gnatg}
893 switch to check the coding style.
894 (Note that you should look at
895 @file{style.adb} to see the lexical rules enforced by
896 @option{-gnatg}).
897 @cindex @option{-gnatg} option (to gcc)
898 @cindex @file{style.adb} file
899
900 @item
901 Each source file should contain only one compilation unit.
902
903 @item
904 Filenames should be 8 or fewer characters, followed by the @code{.adb}
905 extension for a body or @code{.ads} for a spec.
906 @cindex File name length
907
908 @item
909 Unit names should be distinct when ``krunch''ed to 8 characters
910 (see @file{krunch.ads}) and the filenames should match the unit name,
911 except that they are all lower case.
912 @cindex @file{krunch.ads} file
913 @end itemize
914
915
916 @c **********************************
917 @c * GNU Free Documentation License *
918 @c **********************************
919 @include fdl.texi
920 @c GNU Free Documentation License
921 @cindex GNU Free Documentation License
922
923 @node Index,,GNU Free Documentation License, Top
924 @unnumberedsec Index
925
926 @printindex cp
927
928 @contents
929
930 @bye