2 Lexical Elements

2.1 Character Set and Separators

• The character set used should be plain 7-bit ASCII. The only separators allowed are space and the end-of-line sequence. No other control character or format effector (such as HT, VT, FF) should be used. The normal end-of-line sequence is used, which may be LF, CR/LF or CR, depending on the host system. An optional SUB (16#1A#) may be present as the last character in the file on hosts using that character as file terminator.
• Files that are checked in or distributed should be in host format.
• A line should never be longer than 79 characters, not counting the line separator.
• Lines must not have trailing blanks.
• Indentation is 3 characters per level for if statements, loops, and case statements. For exact information on required spacing between lexical elements, see file style.adb.

2.2 Identifiers

• Identifiers will start with an upper case letter, and each letter following an underscore will be upper case. Short acronyms may be all upper case. All other letters are lower case. An exception is for identifiers matching a foreign language. In particular, we use all lower case where appropriate for C.
• Use underscores to separate words in an identifier.
• Try to limit your use of abbreviations in identifiers. It is ok to make a few abbreviations, explain what they mean, and then use them frequently, but don’t use lots of obscure abbreviations. An example is the ALI word which stands for Ada Library Information and is by convention always written in upper-case when used in entity names.

         procedure Find_ALI_Files;
  

• Don’t use the variable name I, use J instead; I is too easily confused with 1 in some fonts. Similarly don’t use the variable O, which is too easily mistaken for the number 0.

2.3 Numeric Literals

• Numeric literals should include underscores where helpful for readability.

        1_000_000
        16#8000_0000#
        3.14159_26535_89793_23846
  

2.4 Reserved Words

• Reserved words use all lower case.

         return else
  

• The words Access, Delta and Digits are capitalized when used as attribute_designator.

2.5 Comments

• A comment starts with -- 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 --. It is also acceptable to have only one space between -- and the start of the comment when the comment is at the end of a line, after some Ada code.
• Every sentence in a comment should start with an upper-case letter (including the first letter of the comment).
• 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, e.g. to make paragraph separations within a single comment, these blank lines do have a -- (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.

         z : Integer;
         --  Integer value for storing value of z
         --
         --  The previous line was a blank line.
  

• Comments that are dubious or incomplete, or that comment on possibly wrong or incomplete code, should be preceded or followed by ???.
• Comments in a subprogram body must generally be surrounded by blank lines. An exception is a comment that follows a line containing a single keyword (begin, else, loop):

         begin
            --  Comment for the next statement
  
            A := 5;
  
            --  Comment for the B statement
  
            B := 6;
         end;
  

• In sequences of statements, comments at the end of the lines should be aligned.

          My_Identifier := 5;      --  First comment
          Other_Id := 6;           --  Second comment
  

• Short comments that fit on a single line are not ended with a period. Comments taking more than a line are punctuated in the normal manner.
• Comments should focus on why instead of what. Descriptions of what subprograms do go with the specification.
• Comments describing a subprogram spec should specifically mention the formal argument names. General rule: write a comment that does not depend on the names of things. The names are supplementary, not sufficient, as comments.
• Do not put two spaces after periods in comments.