Editing Indentation style (section)

== C/C++ styles ==

Attributes of [[C language|C]], [[C++]] and other [[curly-brace programming language]] coding style include but are not limited to:
* Placement of [[curly braces|braces]] relative to other code elements
* Use of [[tab character|tabs]] or [[space character|spaces]]
* Wrapping single-statement blocks in braces. Advocates cite the advantage that resulting code is safer since inserting a statement cannot result in control flow that disagrees with indentation. A cited disadvantage is that the code is longer since one line is needed for the closing brace of a block (except for the <code>else if</code> construct and a <code>do{}while</code> block).

=== K&R ===

The Kernighan & Ritchie (K&R) style is commonly used for C and C++ code and is the basis for many derivative styles. It is used in the original Unix kernel, [[Brian Kernighan|Kernighan]] and [[Dennis Ritchie|Ritchie]]'s book ''[[The C Programming Language]]'', as well as Kernighan and [[P. J. Plauger|Plauger]]'s book ''[[The Elements of Programming Style]]''.

Although ''[[The C Programming Language]]'' does not explicitly define this style, it follows it consistently. From the book:
<blockquote>
The position of braces is less important, although people hold passionate beliefs. We have chosen one of several popular styles. Pick a style that suits you, then use it consistently.
</blockquote>

In this style, a function has its opening and closing braces on their own lines and with the same indentation as the declaration, while the statements in the body of the function are indented an additional level. A multi-statement block inside a function, however, has its opening brace on the same line as its control clause while the closing brace remains on its own line unless followed by a keyword such as <code>else</code> or <code>while</code>.

Example code:

<syntaxhighlight lang="c">
int main(int argc, char *argv[])
{
    while (x == y) {
        do_something();
        do_something_else();
        if (some_error)
            fix_issue(); // single-statement block without braces
        else
            continue_as_usual();
    }
    final_thing();
}
</syntaxhighlight>

==== Egyptian braces ====

{{anchor|Egyptian}}
The non-[[typographic alignment|aligned]] braces of the multi-line blocks are nicknamed "Egyptian braces" (or "Egyptian brackets") for their resemblance to arms in some fanciful poses of ancient Egyptians.<ref>{{cite web |title=Java Style Guide |url=https://www.seas.upenn.edu/~cis120/current/java_style.shtml#f |quote=Using either "Egyptian" curly braces or C-style curly braces is acceptable |url-status=dead |archive-url=https://web.archive.org/web/20180712222126/https://www.seas.upenn.edu/~cis120/current/java_style.shtml |archive-date=2018-07-12}}</ref><ref>{{cite web |title=Egyptian brackets |url=http://foldoc.org/Egyptian+brackets |website=[[Foldoc]] |quote=A {{sic|humou|rous}} term for K&R indent style, referring to the "one hand up in front, one down behind" pose}}</ref><ref>{{cite web |title=Google JavaScript Style Guide |url=https://google.github.io/styleguide/jsguide.html#formatting-nonempty-blocks |quote=Braces follow the Kernighan and Ritchie style ("Egyptian brackets") for nonempty blocks and block-like constructs}}</ref>

==== Single statements ====

A single-statement block does not have braces, which is a cause of easy-to-miss bugs such as the [[Unreachable code#goto fail bug|goto fail bug]].

=== One True Brace ===
{{anchor|Variant: 1TBS}}
{{anchor|1TBS|OTBS|1TBF}}

The ''One True Brace Style'' <ref>{{cite book |url={{google books|id=vweTteq3OLQC|page=51|plain-url=yes}} |title=Checking C programs with Lint |first=Ian F. |last=Darwin |publisher=O'Reilly and Assosciates |location=California |page=51 |isbn=9780937175309|year=1988 }}</ref> (abbreviated 1TBS or OTBS<ref name="catb.org">{{Cite web|url=http://catb.org/jargon/html/0/one-TBS.html|title=1TBS}}</ref>) is like the K&R style, but functions are formatted like multi-statement blocks with the opening brace on the same line as the declaration, and braces are ''not'' omitted for a single-statement block.<ref name=onetruestyle>{{cite web |url=http://2ality.com/2013/01/brace-styles.html |title=Brace styles and JavaScript |date=7 January 2013 |access-date=8 November 2018}}</ref>

<syntaxhighlight lang="cpp">
bool is_negative(int x) {
    if (x < 0) {
        return true;
    } else {
        return false;
    }
}
</syntaxhighlight>

Although not required by languages such as C/C++, using braces for single-statement blocks ensures that inserting a statement does not result in control flow that disagrees with indenting, as seen for example in Apple's infamous [[Unreachable code#goto fail bug|goto fail bug]].

Cited advantages include shorter code (than K&R) since the starting brace needs no extra line, that the ending brace lines up with the statement it conceptually belongs to, and the perceived stylistic consistency of using the same brace style in both function bodies and multi-line statement blocks.<ref name="kernel.coding-style" />

Sources disagree as to the meaning of One True Brace Style. Some say that it is the variation specified here,<ref name=onetruestyle /> while others say it is "hacker jargon" for K&R.<ref name=jargon>{{cite web |url=http://www.catb.org/jargon/html/I/indent-style.html |title=The Jargon File |version=4.4.7 |date=29 December 2003 |access-date=18 August 2014}}</ref>

=== Linux kernel ===

The [[Linux kernel]] source tree is styled in a variant of K&R.<ref>A detailed description of the style is given at [https://www.kernel.org/doc/html/latest/process/coding-style.html kernel.org].</ref> [[Linus Torvalds]] advises contributors to follow it. Attributes include:

* Uses [[tab character]]s for indentation (not spaces) and assumes [[tab stop]]s every 8 spaces
* Brace layout matches K&R, with the braces of function definitions on their own lines and the opening brace of compound statements on the same line as the control clause, separated by a space
* Labels in a <code>switch</code> statement are aligned with the enclosing block (there is only one level of indents)
* Maximum line length is 100 characters although the pre-2020 limit of 80 characters is preferred.<ref>{{cite web |last1=Larabel |first1=Michael |title=The Linux Kernel Deprecates The 80 Character Line Coding Style |url=https://www.phoronix.com/scan.php?page=news_item&px=Linux-Kernel-Deprecates-80-Col |website=Phoronix |publisher=Phoronix Media |access-date=1 May 2022}}</ref>
* A single-statement body of a compound statement (such as if, while, and do-while) does not need to be surrounded by curly braces. If, however, one or more of the substatements in an <code>if-else</code> statement require braces, then both substatements should be wrapped in braces:

<syntaxhighlight lang=c>
int power(int x, int y)
{
        int result;

        if (y < 0) {
                result = 0;
        } else {
                result = 1;
                while (y-- > 0)
                        result *= x;
        }
        return result;
}
</syntaxhighlight>

=== Java ===

A significant body of [[Java (programming language)|Java]] code uses a variant of the K&R style in which the opening brace is on the same line not only for the blocks inside a function, but also for class or method declarations.
This style is widespread largely because [[Sun Microsystems]]'s original style guides<ref>{{cite web |url=http://developers.sun.com/prodtech/cc/products/archive/whitepapers/java-style.pdf |title=Java Coding Style Guide |last=Reddy |first=Achut |publisher=Sun Microsystems |date=30 March 2000 |access-date=30 May 2008 |url-status=dead |archive-url=https://web.archive.org/web/20060228095122/http://developers.sun.com/prodtech/cc/products/archive/whitepapers/java-style.pdf |archive-date=28 February 2006}}</ref><ref>{{cite web |url=http://java.sun.com/docs/codeconv/CodeConventions.pdf |title=Java Code Conventions |publisher=Sun Microsystems |date=12 September 1997 |access-date=30 May 2008 |url-status=dead |archive-url=https://web.archive.org/web/20080513084244/http://java.sun.com/docs/codeconv/CodeConventions.pdf |archive-date=13 May 2008}}</ref><ref>{{cite web
| url=http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html
| title=Code Conventions for the Java Programming Language
| publisher=Sun Microsystems
| date=20 March 1997
| access-date=30 May 2008}}</ref> used this K&R variant, and as a result, most of the standard source code for the [[Java Class Library|Java API]] is written in this style. It is also a popular indentation style for [[ActionScript]] and [[JavaScript]], along with the [[#Allman style|Allman style]].

=== Stroustrup ===

[[Bjarne Stroustrup]] adapted the K&R style for C++ in his books, such as ''Programming: Principles and Practice using C++'' and ''[[The C++ Programming Language]]''.<ref name="ppp">{{cite web |url=https://www.stroustrup.com/Programming/PPP-style.pdf |title=PPP Style Guide |first=Bjarne |last=Stroustrup |date=September 2010}}</ref>

Unlike the variants above, Stroustrup does not use a "cuddled else". Thus, Stroustrup would write<ref name="ppp" />

<syntaxhighlight lang=c>
    if (x < 0) {
        puts("Negative");
        negative(x);
    }
    else {
        puts("Non-negative");
        nonnegative(x);
    }
</syntaxhighlight>

Stroustrup extends K&R style for classes, writing them as follows:

<syntaxhighlight lang=cpp>
    class Vector {
    public:
        // construct a Vector
        Vector(int s) :elem(new double[s]), sz(s) { }
        // element access: subscripting
        double& operator[](int i) { return elem[i]; }
        int size() { return sz; }
    private:
        // pointer to the elements
        double * elem;
        // number of elements
        int sz;
    };
</syntaxhighlight>

Stroustrup does not indent the labels {{code|public:}} and {{code|private:}}. Also, in this style, while the opening brace of a function starts on a new line, the opening brace of a class is on the same line as the class name.

Stroustrup allows writing short functions all on one line. Stroustrup style is a named indentation style available in the editor [[Emacs]]. Stroustrup encourages a K&R-derived style layout with C++ as stated in his modern ''C++ Core Guidelines''.<ref>{{cite web |last1=Stroustrup |first1=Bjarne |title=C++ Core Guidelines |url=https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#nl17-use-kr-derived-layout |website=GitHub |access-date=3 November 2018}}</ref>

=== BSD KNF ===

The [[Berkeley Software Distribution]] (BSD) operating systems uses a style that is sometimes termed [[kernel normal form]] (KNF). Although mostly intended for kernel code, it is also widely used in [[userland (computing)|userland]] code. It is essentially a thoroughly documented variant of K&R style as used in the Bell Labs version 6 & 7 [[Unix]] source code.<ref name="C Style and Coding Standards for SunOS">{{cite news |last1=Shannon |first1=Bill |title=C Style and Coding Standards for SunOS |url=https://www.cis.upenn.edu/~lee/06cse480/data/cstyle.ms.pdf |access-date=15 June 2019 |version=1.8 |publisher=Sun Microsystems, Inc. |date=19 August 1996}}</ref>

The SunOS kernel and userland uses a similar indentation style.<ref name="C Style and Coding Standards for SunOS" /> Like KNF, this also was based on AT&T style documents and is sometimes termed Bill Joy Normal Form.<ref name="DTraceToolkit Style Guide">{{cite web |last1=Gregg |first1=Brendan |title=DTraceToolkit Style Guide |url=http://www.brendangregg.com/DTraceToolkit/style.html |access-date=6 February 2015}}</ref> The SunOS guideline was published in 1996; ANSI C is discussed briefly. The correctness of the indentation of a list of source files can be verified by the ''cstyle'' program written by Bill Shannon.<ref name="C Style and Coding Standards for SunOS" /><ref name="DTraceToolkit Style Guide" /><ref name="illumos-gate cstyle">{{cite web |url=https://github.com/illumos/illumos-gate/blob/master/usr/src/tools/scripts/cstyle.pl |title=cstyle.pl |last1=Shannon |first1=Bill |date=9 September 1998 |website=illumos-gate |publisher=Sun Microsystems, Inc. |access-date=6 February 2015 |version=1.58}}</ref>

In this style, the hard tabulator (ts in [[Vi (text editor)|vi]]) is kept at eight columns, while a soft tabulator is often defined as a helper also (sw in vi), and set at four. The hard tabulators are used to indent code blocks, while a soft tabulator (four spaces) of additional indentation is used for all continuing lines that must be split over multiple lines.

Moreover, function calls do not use a space before the parenthesis, although C-language native statements such as <code>if</code>, <code>while</code>, <code>do</code>, <code>switch</code> and <code>return</code> do (in the case where <code>return</code> is used with parens). Functions that declare no local variables in their top-level block should also leave an empty line after their opening block brace.

Examples:

<syntaxhighlight lang=c>
while (x == y) {
        something();
        something_else();
}
final_thing();
</syntaxhighlight>

<syntaxhighlight lang=c>
if (data != NULL && res > 0) {
        if (JS_DefineProperty(cx, o, "data",
            STRING_TO_JSVAL(JS_NewStringCopyN(cx, data, res)),
            NULL, NULL, JSPROP_ENUMERATE) != 0) {
                QUEUE_EXCEPTION("Internal error!");
                goto err;
        }
        PQfreemem(data);
} else {
        if (JS_DefineProperty(cx, o, "data", OBJECT_TO_JSVAL(NULL),
            NULL, NULL, JSPROP_ENUMERATE) != 0) {
                QUEUE_EXCEPTION("Internal error!");
                goto err;
        }
}
</syntaxhighlight>

<syntaxhighlight lang=c>
static JSBool
pgresult_constructor(JSContext *cx, JSObject *obj, uintN argc,
    jsval *argv, jsval *rval)
{

        QUEUE_EXCEPTION("PGresult class not user-instantiable");

        return (JS_FALSE);
}
</syntaxhighlight>

=== Allman ===
{{anchor|Allman|Allman style|BSD/Allman style}}

The Allman style is named after [[Eric Allman]]. It is also sometimes termed ''BSD style'' since Allman wrote many of the utilities for [[Berkeley Software Distribution|BSD]] Unix (although this should not be confused with the different "BSD KNF style"; see above).

This style puts the brace associated with a control statement on the next line, indented to the same level as the control statement. Statements within the braces are indented to the next level.<ref name="jargon"/>

<syntaxhighlight lang=c>
while (x == y)
{
    something();
    something_else();
}

final_thing();
</syntaxhighlight>

This style is similar to the standard indentation used by the [[Pascal (programming language)|Pascal]] languages and [[Transact-SQL]], where the braces are equivalent to the keywords <code>begin</code> and <code>end</code>.

<syntaxhighlight lang=pascal>
(* Example Allman code indentation style in Pascal *)
procedure dosomething(x, y: Integer);
begin
    while x = y do
    begin
        something();
        something_else();
    end;
end;
</syntaxhighlight>

Consequences of this style are that the indented code is clearly set apart from the containing statement by lines that are almost all [[Whitespace character|whitespace]] and the closing brace lines up in the same column as the opening brace. Some people feel this makes it easy to find matching braces. The blocking style also delineates the block of code from the associated control statement. Commenting out or removing a control statement or block of code, or [[code refactoring]], are all less likely to introduce syntax errors via dangling or missing braces. Also, it is consistent with brace placement for the outer-function block.

For example, the following is still correct syntactically:

<syntaxhighlight lang=c>
// while (x == y)
{
    something();
    something_else();
}
</syntaxhighlight>
As is this:
<syntaxhighlight lang=c>
// for (int i=0; i < x; i++)
// while (x == y)
if (x == y)
{
    something();
    something_else();
}
</syntaxhighlight>

Even like this, with conditional compilation:

<syntaxhighlight lang=c>
    int c;
#ifdef HAS_GETCH
    while ((c = getch()) != EOF)
#else
    while ((c = getchar()) != EOF)
#endif
    {
        do_something(c);
    }
</syntaxhighlight>

==== Variant: Allman-8 ====
Allman-8 uses the 8-space indentation tabs and 80-column limit of the Linux Kernel variant of K&R. The style purportedly helps improve readability on projectors. Also, the indentation size and column restriction help create a visual cue for identifying excessive nesting of code blocks. These advantages combine to help provide newer developers and learners implicit guidance to manage code complexity.{{Citation needed|date=October 2016}}

=== Whitesmiths ===
The Whitesmiths style, also sometimes termed Wishart style, was originally used in the documentation for the first commercial C compiler, the [[Whitesmiths]] Compiler. It was also popular in the early days of Windows, since it was used in three influential Windows programming books, ''[[Programmer's Guide to Windows]]'' by [[David Durant|Durant]], [[Geta Carlson|Carlson]] & [[Paul Yao|Yao]], ''[[Programming Windows]]'' by [[Charles Petzold|Petzold]], and ''[[Windows 3.0 Power Programming Techniques]]'' by [[Peter Norton|Norton]] & Yao.

Whitesmiths, along with [[#Allman style|Allman]], were claimed to have been the most common bracing styles in 1991 by the [[Jargon File]], with roughly equal popularity at the time.<ref name=jargon/><ref name="jargon243">{{cite web |url=http://www.catb.org/~esr/jargon/oldversions/jarg243.txt |title=The Jargon File (Version 2.4.3) |version=2.4.3 |date=23 January 1991 |access-date=14 May 2024}}</ref>

This style puts the brace associated with a control statement on the next line, indented. Statements within the braces are indented to the same level as the braces.

Like Ratliff style, the closing brace is indented the same as statements within the braces.<ref name="mcconnell" />

<syntaxhighlight lang=c>
while (x == y)
    {
    something();
    something_else();
    }

final_thing();
</syntaxhighlight>

The advantages of this style are similar to those of the [[#Allman style|Allman style]]. Blocks are clearly set apart from control statements. The alignment of the braces with the block emphasizes that the full block is conceptually, and programmatically, one compound statement. Indenting the braces emphasizes that they are subordinate to the control statement. The ending brace no longer lines up with the statement, but instead with the opening brace.

An example:

<syntaxhighlight lang=c>
if (data != NULL && res > 0)
    {
    if (!JS_DefineProperty(cx, o, "data", STRING_TO_JSVAL(JS_NewStringCopyN(cx, data, res)), NULL, NULL, JSPROP_ENUMERATE))
        {
        QUEUE_EXCEPTION("Internal error!");
        goto err;
        }
    PQfreemem(data);
    }
else if (!JS_DefineProperty(cx, o, "data", OBJECT_TO_JSVAL(NULL), NULL, NULL, JSPROP_ENUMERATE))
    {
    QUEUE_EXCEPTION("Internal error!");
    goto err;
    }
</syntaxhighlight>

<code>else if</code> are treated as statement, much like the <code>#elif</code> preprocessor statement.

=== GNU ===
{{Main article|GNU coding standards}}

Like the [[#Allman style|Allman]] and [[#Whitesmiths|Whitesmiths]] styles, [[GNU]] style puts braces on a line by themselves, indented by two spaces, except when opening a function definition, where they are not indented.<ref name="gnu.org">{{cite web
|url=https://www.gnu.org/prep/standards/html_node/Formatting.html
|title=Formatting Your Source Code
|website=[[GNU Coding Standards]]
|access-date=6 June 2016
}}</ref> In either case, the contained code is indented by two spaces from the braces.

Popularised by [[Richard Stallman]], the layout may be influenced by his background of writing [[Lisp (programming language)|Lisp]] code.<ref name="gnu.org-lisp">{{cite web |url=https://www.gnu.org/gnu/rms-lisp.html |title=My Lisp Experiences and the Development of GNU Emacs (Transcript of speech at the International Lisp Conference) |first=Richard |last=Stallman |date=28 October 2002 |access-date=6 June 2016}}</ref> In Lisp, the equivalent to a block (a progn) is a first-class data entity, and giving it its own indentation level helps to emphasize that, whereas in C, a block is only syntax. This style can also be found in some [[ALGOL]] and [[XPL]] programming language textbooks from the 1960s and 1970s.<ref>{{cite book |last1=Baumann |first1=Richard |author-link1=:de:Richard Baumann (Mathematiker) |last2=Feliciano |first2=Manuel<!--, Jr.? --> |last3=Bauer |first3=Friedrich Ludwig |author-link3=Friedrich Ludwig Bauer |last4=Samelson |first4=Klaus |author-link4=Klaus Samelson |date=1964 |title=Introduction to ALGOL – A primer for the non-specialist, emphasizing the practical uses of the algorithmic language |series=Series in Automatic Computation |publisher=[[Prentice-Hall, Inc.]] |publication-place=Englewood Cliffs, New Jersey, USA |isbn=0-13-477828-6 |lccn=64-10740 |id=ark:/13960/t6qz35p37 |url=https://archive.org/details/introductiontoal00baum |access-date=2022-10-23}}</ref><ref>W. M. McKeeman, J. J. Horning, and D. B. Wortman, ''A Compiler Generator'', 1970, https://archive.org/details/compilergenerato00mcke</ref>{{discuss|editorial option in lieu of source}}

Although not indentation per se, GNU coding style also includes a space after a function name {{endash}} before the left parenthesis of an argument list.<ref name="gnu.org"/>

<syntaxhighlight lang=c>
static char *
concat (char *s1, char *s2)
{
  while (x == y)
    {
      something ();
      something_else ();
    }
  final_thing ();
}
</syntaxhighlight>

This style combines the advantages of [[#Allman style|Allman]] and [[#Whitesmiths|Whitesmiths]], thereby removing the possible Whitesmiths disadvantage of braces not standing out from the block. One disadvantage is that the ending brace no longer lines up with the statement it conceptually belongs to. Another possible disadvantage is that it might waste space by using two visual levels of indents for one conceptual level, but in reality this is unlikely because, in systems with single-level indentation, each level is usually at least 4 spaces, same as 2 * 2 spaces in GNU style.

The [[GNU Coding Standards]] recommend this style, and nearly all maintainers of [[GNU project]] software use it.{{Citation needed|date=February 2013}}

The [[GNU Emacs]] text editor and the GNU systems' [[indent (Unix)|indent]] command will reformat code according to this style by default.<ref>Tested on the sample source code above on Ubuntu 18.04 with GNU indent 2.2.11 and GNU Emacs 25.2.2 started with <code>emacs --no-init-file</code>.</ref> Those who do not use GNU Emacs, or similarly extensible/customisable editors, may find that the automatic indentation settings of their editor are unhelpful for this style. However, many editors defaulting to KNF style cope well with the GNU style when the tab width is set to two spaces; likewise, GNU Emacs adapts well to KNF style by simply setting the tab width to eight spaces. In both cases, automatic reformatting destroys the original spacing, but automatic line indenting will work properly.

[[Steve McConnell]], in his book [[Code Complete]], advises against using this style: he marks a code sample which uses it with a "Coding Horror" icon, symbolizing especially dangerous code, and states that it impedes readability.<ref name="mcconnell" >{{cite book |title=Code Complete: A practical handbook of software construction |url=https://archive.org/details/codecomplete0000mcco |url-access=registration |last=McConnell |first=Steve |publisher=Microsoft Press |year=2004 |isbn=978-0-7356-1967-8 |location=Redmond, WA |pages=[https://archive.org/details/codecomplete0000mcco/page/746 746–747] |author-link=Steve McConnell}}</ref> The [[Linux kernel]] coding style documentation also recommends against this style, urging readers to burn a copy of the GNU coding standards as a "great symbolic gesture".<ref name="kernel.coding-style" >{{cite web |title=Linux kernel coding style |url=https://www.kernel.org/doc/Documentation/process/coding-style.rst |access-date=1 January 2017}}</ref>

=== Horstmann ===
The 1997 edition of ''Computing Concepts with C++ Essentials'' by Cay S. Horstmann adapts [[#Allman style|Allman]] by placing the first statement of a block on the same line as the opening brace. This style is also used in examples in Jensen and Wirth's ''Pascal User Manual and Report''.<ref>{{cite book |first1=Kathleen |last1=Jensen |first2=Niklaus |last2=Wirth |title=PASCAL User Manual and Report |publisher=Springer-Verlag |year=1974}}</ref>

<syntaxhighlight lang=c>
while (x == y)
{   something();
    something_else();
    //...
    if (x < 0)
    {   printf("Negative");
        negative(x);
    }
    else
    {   printf("Non-negative");
        nonnegative(x);
    }
}
final_thing();
</syntaxhighlight>

This style combines the advantages of [[#Allman style|Allman]] by keeping the vertical alignment of the braces for readability, and identifying blocks easily, with the saving of a line of the K&R style. However, the 2003 edition now uses Allman style throughout.<ref>[http://www.horstmann.com/bigcpp/styleguide.html Horstmann Style Guide]</ref>

=== Pico ===
This is the style used most commonly in the language [[Pico (programming language)|Pico]] by its designers.  Pico lacks return statements, and uses semicolons as statement separators instead of terminators. It yields this syntax:<ref>{{Cite book|last=Ohno|first=Asako|title=2013 IEEE Frontiers in Education Conference (FIE) |chapter=A methodology to teach exemplary coding style considering students' coding style feature contains fluctuations |date=2013|pages=1908–1910|doi=10.1109/fie.2013.6685167|isbn=9781467352611 |s2cid=28385526}}</ref>

<!--no geshi support for pico-->
<pre>
stuff(n):
{ x: 3 * n;
  y: do_stuff(x);
  y + x }
</pre>

The advantages and disadvantages are similar to those of saving screen real estate with K&R style.  An added advantage is that the starting and closing braces are consistent in application (both share space with a line of code), relative to K&R style, where one brace shares space with a line of code and one brace has a line alone.

=== Ratliff ===
In the book ''Programmers at Work'',
<ref name=lammers>{{cite book |last=Lammers |first=Susan |title=Programmers at Work |year=1986 |publisher=Microsoft Press |isbn=978-0-914845-71-3 |url-access=registration |url=https://archive.org/details/programmersatwor00lamm_0 }}</ref>
C. Wayne Ratliff,
the original programmer behind the popular [[dBase]]-II and -III [[fourth-generation programming language]]s, 
discussed a style that is like 1TBS but the closing brace lines up with the indentation of the nested block. 
He indicated that the style was originally documented in material from [[Digital Research]] Inc. This style has sometimes been termed ''banner'' style,<ref name=pattee>{{cite web |last1=Pattee |first1=Jim |title=Artistic Style 2.05 Documentation |url=http://astyle.sourceforge.net/astyle.html |website=Artistic Style |access-date=24 April 2015}}</ref> possibly for the resemblance to a banner hanging from a pole. In this style, which is to [[#Whitesmiths|Whitesmiths]] as K&R is to Allman, the closing control is indented the same as the last item in the list (and thus properly loses salience)<ref name="mcconnell" /> The style can make visual scanning easier for some, since the ''headers'' of any block are the only thing exdented at that level (the theory being that the closing control of the prior block interferes with the visual flow of the next block header in the K&R and Allman styles). Kernighan and Plauger use this style in the Ratfor code in ''Software Tools''.<ref>{{cite book |first1=Brian W. |last1=Kernighan |first2=P. J. |last2=Plauger |title=Software Tools |url=https://archive.org/details/softwaretools00kern |url-access=registration |publisher=Addison-Wesley |year=1976|isbn=9780201036695 }}</ref>

<syntaxhighlight lang=c>
 // In C
 for (i = 0; i < 10; i++) {
     if (i % 2 == 0) {
         do_something(i);
         }
     else {
         do_something_else(i);
         }
     }
</syntaxhighlight>