Indentation style

from Wikipedia, the free encyclopedia

As Indent (Engl. Indent style ) is the way designated source code of programs indent for readability and enclosing syntax elements such as braces {}to position. As an alternative name is therefore also sometimes called " bracket style " (English. Brace style ) to be found.

There are four common indentation styles for the C programming language , which have also been adopted in programming and scripting languages ​​with C-like syntax such as C ++ , Java , JavaScript , Perl or C # . There is a mandatory indentation style for the Python programming language .

The positioning of the curly braces is probably the most controversial element of any programming style .

Elements of indentation style

The indentation style refers to:

  • Positioning of enclosing syntax elements, in particular {}and()
  • Depth of indentation
  • Use of spaces before {and(
  • Use of tab characters for indentation.

It is often recommended not to format a source text in such a way that the indentation only becomes visible when the tab step size is changed to a different value, e.g. B. 4 instead of 8 characters. Many editors use the value of 8 spaces as the default setting for the tab spacing. In order to avoid the dependency of the representation on the set tabulator step size completely, most indentation styles advise against the use of tabulator characters.

Positioning of enclosing syntax elements

Enclosing syntax elements are those syntax elements of a language that are used to group an indefinite number of elements, but not exclusively when the elements extend over several lines of source text. In languages ​​with C -like syntax , e.g. B. C ++ , Java and C # , in languages ​​with Pascal- like syntax, e.g. B. Modula-2 , Oberon and Cluster as well as some other languages, these elements are of central importance when designing a source text with regard to its syntax and readability.

Positioning in Pascal

Pascal-like languages ​​use specially defined keywords, mostly BEGIN, DOand END. In practice, the positioning of these elements is rarely discussed; it is usually carried out as demonstrated by Niklaus Wirth in the literature. BEGINThe indentation of the outer block is still on a separate line, DObut the DOrequired statement is written at the end of the previous line together with the . The content of the block introduced by BEGINor DOis ENDindented up to only . That ENDstands out, i.e. H. in the indentation of the outer block again on a separate line.

Example: Positioning of the enclosing syntax elements in Oberon

  PROCEDURE Add(VAR x, y: INTEGER)
  BEGIN
    WHILE (y != 0) DO
      y := y - 1;
      x := x + 1;
    END
  END Add;

Positioning in C

C-like languages ​​use a pair of curly braces {and to enclose }. In practice, these brackets can be positioned almost anywhere, so that several different styles have developed, none of which can be described as dominant.

Positioning in XML and SGML based languages

In XML- and SGML -based languages, e.g. B. HTML , has established itself to indent the content of elements between the start tag and the end tag. A multi-line division is increasingly found for attributes, especially when clarity is required.

Example: Indentation in an XHTML source text

 <?xml version="1.0"?>
 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
 <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="de">
     <head>
         <title>Einrückung in XML</title>
     </head>
     <body>
         <h1>Einrückung in XML</h1>
         <p>
             Dieses Dokument ist ein Beispiel für Einrückung in XML / SGML.
             <br />
             In diesem Beispiel beträgt die Einrückungstiefe 4 Leerzeichen.
         </p>
     </body>
 </html>

Example: Indentation in an Ant source text

 <?xml version="1.0"?>
 <!--
   - Daimonin Editor build file
   -->
 <project
     name    = "Daimonin Editor"
     default = "compile"
 >
     <target
         name        = "compile"
         description = "compile Daimonin Editor"
     >
         <javac
             srcdir   = "src"
             destdir  = "classes"
             encoding = "utf-8"
             source   = "1.5"
             target   = "1.5"
             debug    = "no"
         />
     </target>
 </project>

Indentation depth

The indentation depth determines how far the contents of a block are indented. Indentation depths of 4 or 8 spaces are particularly widespread, but 2 or 3 spaces are also not uncommon. An experiment from 1983 with Pascal Code shows that the indentation depth has a significant influence on the understandability of the code. According to the results, indentation depths in the range of 2 to 4 spaces achieve the best intelligibility.

If a maximum text width is specified or aimed for, too large an indentation depth leads to more frequent line breaks. This results from the shorter remaining line length after the indentation, within which longer statements or expressions can no longer be accommodated. This effect contributes to the decrease in legibility at higher indentation depths. The remaining line length can be calculated as follows: remaining line length = text width - nesting depth · indentation depth . With a text width of 79 characters, an indentation depth of 8 spaces and a nesting depth of 3 levels, the remaining line length is 55 characters.

Example: Java source text with an indentation depth of 2 spaces

 public class Hello {
   public static void main(String... args) {
     if (args.length > 0) {
       for (String arg : args) {
         System.out.println("Hello, " + arg + "!");
       }
     } else {
       System.out.println("Hello, world!");
     }
   }
 }

Example: Java source text with an indentation depth of 4 spaces

 public class Hello {
     public static void main(String... args) {
         if (args.length > 0) {
             for (String arg : args) {
                 System.out.println("Hello, " + arg + "!");
             }
         } else {
             System.out.println("Hello, world!");
         }
     }
 }

Example: Java source text with an indentation depth of 8 spaces

 public class Hello {
         public static void main(String... args) {
                 if (args.length > 0) {
                         for (String arg : args) {
                                 System.out.println("Hello, " + arg + "!");
                         }
                 } else {
                         System.out.println("Hello, world!");
                 }
         }
 }

As you can see, the longer the indentation depth, the longer the lines, which leaves less space for instructions and expressions within a line when the text width is limited.

Use of tabs or spaces

In most programming languages, the indentation of a source text can be done either with spaces or with tabs. Most compilers see no difference in this, so the choice is left to the programmer.

However, there are arguments for or against indenting with spaces or tabs. An indentation with spaces speaks that the indentation depth basically remains the same and the indentation is always recognizable, regardless of which tabulator step size is used. An argument in favor of indentation with tab characters is that every developer can set the tab step size himself and thus determine his personal indentation depth.

It is more important than the choice of the indentation style to consistently stick to the chosen style, since a mixture can lead to problems with the representation.

Example: Source text with mixed indentation (both tab characters and spaces) that was created with a tab step size of 4 and displayed (spaces are represented by dots, tab characters by arrows).

public class Hello {
       public static void main(String... args) {
........if (args.length > 0) {
............for (String arg : args) {
       ............System.out.println("Hello, " + arg + "!");
            }
              } else {
............System.out.println("Hello, world!");
........}
       }
}

The display could be corrected by changing the tabulator step size. For a few editors, e.g. Control information, for example vim , can be included in the source code, which automatically sets the editor to the tabulator increment used. However, these editors are the exception, and there is also no uniform standard for such settings. Without these possibilities, the programmer has to look at each source text visually with mixed source texts, guess the tabulator increments and reset accordingly.

Known indentation styles

Note on the examples

The code examples are used to demonstrate the indentation style. Their content hardly makes sense.

1TBS / K&R / Kernel / Linux / UNIX / Stroustrup / Java / Sun

Example: GNU example in 1TBS

         if (x < foo(y, z)) {
                 qux = bar[4] + 5;
         } else {
                 while (z) {
                         qux += foo(z, z);
                         z--;
                 }
                 return ++x + bar();
         }

The name 1TBS (also OTBS) comes from hacker jargon and stands for “One True Brace Style”, which translates as “the only true brace style”. The name refers to the fact that this style was defined by the C inventors Brian W. Kernighan and Dennis Ritchie .

The positioning of the opening brackets at the end of a line is as popular as it is hated. With poor development tools, carelessness runs the risk of overlooking opening brackets and forgetting to close.

On the other hand, this style has two advantages:

  • Much more code is displayed in the same number of lines.
  • Non-independent subsequent blocks are recognized by the closing curly brace under a closing curly brace in the same column.

The vast majority of Java and ECMAScript programmers use this style. Perl programmers also mostly use 1TBS because they prefer to keep their programs as short as possible anyway.

In the past, C code used 8 spaces per indentation step, but today there are sometimes 4 or 3 spaces. In Java and C ++, an indentation of 4 spaces is the rule.

Variation: Original K&R / Kernel / Linux / UNIX / Stroustrup

Example: GNU example in K&R

 int f(int x, int y, int z)
 {
         if (x < foo(y, z)) {
                 qux = bar[4] + 5;
         } else {
                 while (z) {
                         qux += foo(z, z);
                         z--;
                 }
                 return ++x + bar();
         }
 }

This programming style was used by the C inventors Brian W. Kernighan and Dennis Ritchie (K&R) in their book The C Programming Language (German title: Programmieren in C) and together with Ken Thompson in the development of UNIX and its kernel . The Linus Torvalds Code Conventions for Linux also suggest this style.

The indentation depth shown is that used in the Linux kernel. The indentation of subordinate syntax elements is 8 spaces. This makes it easier to read, even after 20 hours of screen work. An indentation of more than 3 levels is not recommended and a restructuring of the source text is suggested instead.

In contrast to the continuous use of the 1TBS, such as B. in the Java style, the Allman style is used when defining functions.

There are several reasons for the exception for the functions in C:

  • K&R also use exactly this positioning of the brackets
  • It allows you to jump from function to function in an editor without a parser for the respective language (e.g. in vi using [[or ]]).
  • The exception rule offers a particularly high level of readability with broken function definitions:
 static int
 kwrite_args(struct posix_log_entry *rec_hdr, va_list args,
         unsigned char **pvardata)
 {
         // ...
 }
  • Historically, it was not an "optimization", but a necessity that emerged from the function definition syntax of K&R (i.e. pre-ANSI) C-Code, there the opening curly brace separates the type list of the function parameters from the function body:
int foo(a, p)
	int a;
	char *p;
{
	/* ... */
}

If this style is applied to C ++ , it is also called Stroustrup after the inventor of C ++, who extended the K&R style to include elements for C ++. For all new elements, e.g. B. classes, opening curly braces are placed at the end of a line:

 class C : public B {
 public:
         // ...
 };

Variation: Java / Sun

Example: Java-style GNU example

 int f(int x, int y, int z) {
     if (x < foo(y, z)) {
         qux = bar[4] + 5;
     } else {
         while (z) {
             qux += foo(z, z);
             z--;
         }
         return ++x + bar();
     }
 }

This style is recommended by Sun for the Java programming language. This style is also common in C ++. The exception rule to position the curly brackets of methods (= object-oriented function) according to Allman is dispensed with, since methods are nested as elements of classes.

Due to the more frequent nesting, an indentation of 4 instead of 8 spaces is preferred.

Allman / BSD

Example: Allman-style GNU example

 int f(int x, int y, int z)
 {
     if (x < foo(y, z))
     {
         qux = bar[4] + 5;
     }
     else
     {
         while (z)
         {
             qux += foo(z, z);
             z--;
         }
         return ++x + bar();
     }
 }

This style was named after Eric Allman , who wrote a variety of BSD tools, which is why this style is not quite correctly called the BSD style. Since it is the basic setting of Microsoft's Visual Studio development environment , it is widely used in programming for Windows.

The advantage of the Allman style is that the block areas can be easily recognized, which is particularly helpful with higher nesting depths.

Some programmers consider it disadvantageous that this style has a high line consumption. An additional line is required per block compared to 1TBS. In C, C ++ and languages ​​with comparable preprocessors, however, there are situations in which this style also shows significant advantages over 1TBS, namely when using conditional compilation for alternative block introductions.

Example: Advantage of the Allman style with conditional compilation of block introductions

 #if OGRE_PLATFORM == OGRE_PLATFORM_WIN32
 INT WINAPI WinMain( HINSTANCE hInst, HINSTANCE, LPSTR strCmdLine, INT )
 #else
 int main(int argc, char **argv)
 #endif
 {
     // ...
 }

The total number of brackets remains the same even when using conditional compilation, which is important for the correct assignment of opening and closing brackets in text editors with the corresponding functionality.

Note: Although this style is often called the BSD style, the BSD kernel uses 1TBS as is the case for UNIX and Linux, as can be read in the style man pages for the various BSD derivatives.

Horstmann

The Horstmann style is a modification of the Allman style, in which the first instruction after the opening curly bracket is written directly on the same line. The code from above looks like this:

 int f(int x, int y, int z)
 {   if (x < foo(y, z))
     {   qux = bar[4] + 5;
     }
     else
     {   while (z)
         {   qux += foo(z, z);
             z--;
         }
         return ++x + bar();
     }
 }

This style is problematic for VCS tools. If you insert a new instruction between the "{" and the formerly first instruction, this change appears as "a line is replaced by 2 lines" instead of "a new line has been inserted". This means that the original line is marked as “changed”, although it has remained semantically the same.

Whitesmith style

The Whitesmith style was originally used in the documentation of the first commercial C compiler. This style was popular in early Windows programming manuals, including the Programmer's Guide to Windows (Durant, Carlson & Yao), Programming Windows (Petzold), and Windows 3.0 Power Programming Techniques (Norton & Yao).

 int f(int x, int y, int z)
     {
     if (x < foo(y, z))
         {
         qux = bar[4] + 5;
         }
     else
         {
         while (z)
             {
             qux += foo(z, z);
             z--;
             }
         return ++x + bar();
         }
     }

The advantage of this style is that the block clearly separates itself from the control instruction and, in contrast to the Allman style, does not interrupt the reading flow of the block.

GNU style

Example: Original GNU example

 int f (int x, int y, int z)
 {
     if (x < foo (y, z))
       qux = bar[4] + 5;
     else
       {
         while (z)
           {
             qux += foo (z, z);
             z--;
           }
         return ++x + bar ();
       }
 }

This programming style is mainly to be found in GNU projects of the Free Software Foundation and is recommended by them. Outside of the Free Software Foundation it is rarely found and even within the Free Software Foundation it is not used by everyone.

The example mentioned was taken from the GNU Coding Standards . The other examples have been reformatted with respect to indentation and parentheses.

Proponents of the GNU style describe it as particularly legible because the curly brackets in positioning and indentation have their own level. Opponents, on the other hand, argue that this creates some chaos in the source code formatting; legibility and consistent indentation would be made more difficult.

Ratliff style

In the book, Programmers at Work, Wayne Ratliff discussed the style shown below. It starts out similar to 1TBS, but the indentation of the closing bracket is the same as that of the nested block. This style is sometimes referred to as the banner style, arguably because of its resemblance to a banner hanging from a pole. The style can make it easier to visualize, as only the headers of a block protrude to the left at this level.

 // In C
 for (i = 0; i < 10; i++) {
     if (i % 2 == 0) {
         doSomething(i);
         }
     else {
         doSomethingElse(i);
         }
     }

or, in a markup language ...

<table>
  <tr>
    <td> lots of stuff...
      more stuff
      </td>
    <td> alternative for short lines </td>
    <td> etc. </td>
    </tr>
  </table>

<table>
  <tr> ... etc
  </table>

See also

Web links

Individual evidence

  1. ^ A b Richard J. Miara, Joyce A. Musselman, Juan A. Navarro, Ben Shneiderman: Program Indentation and Comprehensibility . In: Communications of the ACM . 26, No. 11, November 1983, pp. 861-867.
  2. ^ "Linux kernel coding style" in the Linux documentation
  3. oracle.com
  4. openbsd.org
  5. freebsd.org
  6. gnu.org