@c o
@c GNAT DOCUMENTATION o
@c o
-@c G N A T C O D I N G S T Y L E o
+@c G N A T C O D I N G S T Y L E o
@c o
-@c Copyright (C) 1992-2004 Ada Core Technologies, Inc. o
-@c o
-@c GNAT is free software; you can redistribute it and/or modify it under o
-@c terms of the GNU General Public License as published by the Free Soft- o
-@c ware Foundation; either version 2, or (at your option) any later ver- o
-@c sion. GNAT is distributed in the hope that it will be useful, but WITH- o
-@c OUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY o
-@c or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License o
-@c for more details. You should have received a copy of the GNU General o
-@c Public License distributed with GNAT; see file COPYING. If not, write o
-@c to the Free Software Foundation, 59 Temple Place - Suite 330, Boston, o
-@c MA 02111-1307, USA. o
+@c GNAT is maintained by Ada Core Technologies Inc (http://www.gnat.com). o
@c o
@c oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
@setfilename gnat-style.info
+@copying
+Copyright @copyright{} 1992-2008, Free Software Foundation, Inc.
+
+Permission is granted to copy, distribute and/or modify this document
+under the terms of the GNU Free Documentation License, Version 1.3 or
+any later version published by the Free Software Foundation; with no
+Invariant Sections, with no Front-Cover Texts and with no Back-Cover
+Texts. A copy of the license is included in the section entitled
+``GNU Free Documentation License''.
+@end copying
+
@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
-@subtitle GNAT, The GNU Ada 95 Compiler
-
+@titlefont{GNAT Coding Style:}
+@sp 1
+@title A Guide for GNAT Developers
+@subtitle GNAT, The GNU Ada Compiler
+@versionsubtitle
@author Ada Core Technologies, Inc.
-
@page
@vskip 0pt plus 1filll
-Copyright @copyright{} 1995-2003, Free Software Foundation
-
-Permission is granted to copy, distribute and/or modify this document
-under the terms of the GNU Free Documentation License, Version 1.1
-or any later version published by the Free Software Foundation;
-with the Invariant Sections being ``GNU Free Documentation License'', with the
-Front-Cover Texts being
-``GNAT Coding Style'' and ``A Guide for GNAT Developers'',
-and with no Back-Cover Texts.
-A copy of the license is included in the section entitled
-``GNU Free Documentation License''.
+@insertcopying
@end titlepage
@raisesections
A Guide for GNAT Developers
@sp 2
@noindent
-GNAT, The GNU Ada 95 Compiler@*
+GNAT, The GNU Ada Compiler@*
@noindent
-Permission is granted to copy, distribute and/or modify this document
-under the terms of the GNU Free Documentation License, Version 1.1
-or any later version published by the Free Software Foundation;
-with the Invariant Sections being ``GNU Free Documentation License'', with the
-Front-Cover Texts being
-``GNAT Coding Style'' and ``A Guide for GNAT Developers''
-and with no Back-Cover Texts.
-A copy of the license is included in the section entitled
-``GNU Free Documentation License''.
+@insertcopying
@end ifnottex
@smallexample
1_000_000
- 16#8000_000#
+ 16#8000_0000#
3.14159_26535_89793_23846
@end smallexample
@end itemize
@itemize @bullet
@item
-A comment starts with @code{--} followed by two spaces).
+A comment starts with @code{--} followed by two spaces.
The only exception to this rule (i.e.@: one space is tolerated) is when the
comment ends with a single space followed by @code{--}.
It is also acceptable to have only one space between @code{--} and the start
When declarations are commented with ``hanging'' comments, i.e.@:
comments after the declaration, there is no blank line before the
comment, and if it is absolutely necessary to have blank lines within
-the comments these blank lines @emph{do} have a @code{--} (unlike the
+the comments, e.g. to make paragraph separations within a single comment,
+these blank lines @emph{do} have a @code{--} (unlike the
normal rule, which is to use entirely blank lines for separating
comment paragraphs). The comment starts at same level of indentation
as code it is commenting.
@node Declarations and Types, Expressions and Names, Lexical Elements,Top
@section Declarations and Types
@c -------------------------------------------------------------------------
-@cindex Declarationa and Types
+@cindex Declarations and Types
@itemize @bullet
@item
@item
Conditions should use short-circuit forms (@code{and then},
-@code{or else}).
+@code{or else}), except when the operands are boolean variables
+or boolean constants.
@cindex Short-circuit forms
@item
@end group
@end smallexample
+@noindent
+There are some cases where complex conditionals can be laid out
+in manners that do not follow these rules to preserve better
+parallelism between branches, e.g.
+
+@smallexample @c adanocomment
+@group
+ if xyz.abc (gef) = 'c'
+ or else
+ xyz.abc (gef) = 'x'
+ then
+ ...
+ end if;
+@end group
+@end smallexample
+
+
@item
Every @code{if} block is preceded and followed by a blank line, except
where it begins or ends a @syntax{sequence_of_statements}.
@itemize @bullet
@item
-Do not write the @code{in} for parameters, especially in functions:
+Do not write the @code{in} for parameters.
@smallexample @c adanocomment
function Length (S : String) return Integer;
@smallexample @c adanocomment
@group
procedure Set_Heading
- (Source : String;
- Count : Natural;
- Pad : Character := Space;
- Fill : Boolean := True);
+ (Source : String;
+ Count : Natural;
+ Pad : Character := Space;
+ Fill : Boolean := True);
@end group
@end smallexample
@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.
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
@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
@item
After the file header comment, the context clause and unit specification
should be the first thing in a @syntax{program_unit}.
+
+@item
+Preelaborate, Pure and Elaborate_Body pragmas should be added right after the
+package name, indented an extra level and using the parameterless form:
+
+@smallexample @c adanocomment
+@group
+ package Preelaborate_Package is
+ pragma Preelaborate;
+ ...
+ end Preelaborate_Package;
+@end group
+@end smallexample
+
@end itemize
@c -------------------------------------------------------------------------
OSDN Git Service
