gcc/ChangeLog ---------------------------------------------------------
[gcc.git] / gcc / ada / gnat-style.texi
index c681b5286a11d5e1f1e6d57138c7c9b8917ab8c4..61fc713c8ab3519114622cfe64fda2e841c6943b 100644 (file)
@@ -27,8 +27,9 @@
 @settitle GNAT Coding Style
 @setchapternewpage odd
 
+@include gcc-common.texi
 
-@dircategory Programming
+@dircategory Software development
 @direntry
 * gnat-style: (gnat-style).      GNAT Coding Style
 @end direntry
 @c %**end of header
 
 @titlepage
-@sp 10
-@title GNAT Coding Style
-@flushright
-@titlefont{A Guide for GNAT Developers}
-@end flushright
-@sp 2
+@titlefont{GNAT Coding Style:}
+@sp 1
+@title @hfill A Guide for GNAT Developers
 @subtitle GNAT, The GNU Ada 95 Compiler
-
+@versionsubtitle
 @author Ada Core Technologies, Inc.
-
 @page
 @vskip 0pt plus 1filll
 
@@ -712,7 +709,7 @@ alternative forms for the above spec are:
 @item
 Function and procedure bodies should usually be sorted alphabetically. Do
 not attempt to sort them in some logical order by functionality. For a
-sequence of subrpgroams specs, a general alphabetical sorting is also
+sequence of subprogram specs, a general alphabetical sorting is also
 usually appropriate, but occasionally it makes sense to group by major
 function, with appropriate headers.
 
@@ -749,7 +746,8 @@ A sequence of declarations may optionally be separated from the following
 begin by a blank line.  Just as we optionally allow blank lines in general
 between declarations, this blank line should be present only if it improves
 readability. Generally we avoid this blank line if the declarative part is
-small (one or two lines) and we include it if the declarative part is long.
+small (one or two lines) and the body has no blank lines, and we include it
+if the declarative part is long or if the body has blank lines.
 
 @item
 If the declarations in a subprogram contain at least one nested
@@ -766,8 +764,78 @@ subprogram, there is a comment line and a blank line:
 @end group
 @end smallexample
 
+@item
+When nested subprograms are present, variables that are referenced by any
+nested subprogram should precede the nested subprogram specs. For variables
+that are not referenced by nested procedures, the declarations can either also
+be before any of the nested subprogram specs (this is the old style, more
+generally used). Or then can come just before the begin, with a header. The
+following example shows the two possible styles:
+
+@smallexample @c adanocomment
+@group
+    procedure Style1 is
+       Var_Referenced_In_Nested      : Integer;
+       Var_Referenced_Only_In_Style1 : Integer;
+
+       proc Nested;
+       --  Comments ...
+
+
+       ------------
+       -- Nested --
+       ------------
+
+       procedure Nested is
+       begin
+          ...
+       end Nested;
+
+    --  Start of processing for Style1
+
+    begin
+       ...
+    end Style1;
+
+@end group
+
+@group
+    procedure Style2 is
+       Var_Referenced_In_Nested : Integer;
+
+       proc Nested;
+       --  Comments ...
+
+       ------------
+       -- Nested --
+       ------------
+
+       procedure Nested is
+       begin
+          ...
+       end Nested;
+
+       --  Local variables
+
+       Var_Referenced_Only_In_Style2 : Integer;
+
+    --  Start of processing for Style2
+
+    begin
+       ...
+    end Style2;
+
+@end group
+@end smallexample
+
+@noindent
+For new code, we generally prefer Style2, but we do not insist on
+modifying all legacy occurrences of Style1, which is still much
+more common in the sources.
+
 @end itemize
 
+
 @c  -------------------------------------------------------------------------
 @node    Packages, Program Structure, Subprograms, Top
 @section Packages and Visibility Rules