Skip to content

Instantly share code, notes, and snippets.

@jesseschalken

jesseschalken/code_style.md

Last active November 14, 2025 17:02
Show Gist options

  • Select an option

    Learn more about clone URLs
  • Save jesseschalken/0f47a2b5a738ced9c845 to your computer and use it in GitHub Desktop.

Select an option

Learn more about clone URLs
Save jesseschalken/0f47a2b5a738ced9c845 to your computer and use it in GitHub Desktop.
Download ZIP

Revisions

  1. jesseschalken revised this gist Jun 28, 2020. 1 changed file with 1 addition and 0 deletions.
    1 change: 1 addition & 0 deletions code_style.md
    View file
    Original file line number Diff line number Diff line change
    @@ -260,6 +260,7 @@ Phabricator (Facebook)|K&R|spaces|2|[Phabricator coding standards](https://secur
    C# Guidelines (Microsoft)|Allman|spaces|4|[link](https://msdn.microsoft.com/en-us/library/vstudio/ff926074.aspx)
    TypeScript (Microsoft)|K&R|spaces|4|[code](https://github.com/microsoft/TypeScript/blob/v3.9.5/src/compiler/core.ts)
    Visual Studio Code (Microsoft)|K&R|tabs|?|[code](https://github.com/microsoft/vscode/blob/master/src/vs/platform/credentials/common/credentials.ts)
    Intel TBB|K&R|spaces|4|[code](https://github.com/oneapi-src/oneTBB/blob/tbb_2020/src/tbb/tbb_bind.cpp)
    Sun Java JRE/JDK (Oracle)|K&R|spaces|2|[code](http://hg.openjdk.java.net/jdk7/jdk7/hotspot/file/9b0ca45cd756/src/cpu/x86/vm/sharedRuntime_x86_64.cpp)
    Linux Kernel|K&R|tabs|8|[Coding Style](https://www.kernel.org/doc/Documentation/CodingStyle)
    IntelliJ (JetBrains)|K&R|spaces|2|[code](https://github.com/JetBrains/intellij-community/blob/idea/202.4357.23/platform/lang-impl/src/com/intellij/ide/CopyPasteDelegator.java)
  2. jesseschalken revised this gist Jun 28, 2020. 1 changed file with 4 additions and 4 deletions.
    8 changes: 4 additions & 4 deletions code_style.md
    View file
    Original file line number Diff line number Diff line change
    @@ -259,9 +259,9 @@ Phabricator (Facebook)|K&R|spaces|2|[Phabricator coding standards](https://secur
    .NET CLR (Microsoft)|Allman|spaces|4|[code](https://github.com/dotnet/coreclr/blob/v3.1.5/src/gcinfo/gcinfodumper.cpp)
    C# Guidelines (Microsoft)|Allman|spaces|4|[link](https://msdn.microsoft.com/en-us/library/vstudio/ff926074.aspx)
    TypeScript (Microsoft)|K&R|spaces|4|[code](https://github.com/microsoft/TypeScript/blob/v3.9.5/src/compiler/core.ts)
    Visual Studio Code (Microsoft)|K&R|tabs|4|[code](https://github.com/microsoft/vscode/blob/master/src/vs/platform/credentials/common/credentials.ts)
    Visual Studio Code (Microsoft)|K&R|tabs|?|[code](https://github.com/microsoft/vscode/blob/master/src/vs/platform/credentials/common/credentials.ts)
    Sun Java JRE/JDK (Oracle)|K&R|spaces|2|[code](http://hg.openjdk.java.net/jdk7/jdk7/hotspot/file/9b0ca45cd756/src/cpu/x86/vm/sharedRuntime_x86_64.cpp)
    Linux Kernel|K&R|tab|8|[Coding Style](https://www.kernel.org/doc/Documentation/CodingStyle)
    Linux Kernel|K&R|tabs|8|[Coding Style](https://www.kernel.org/doc/Documentation/CodingStyle)
    IntelliJ (JetBrains)|K&R|spaces|2|[code](https://github.com/JetBrains/intellij-community/blob/idea/202.4357.23/platform/lang-impl/src/com/intellij/ide/CopyPasteDelegator.java)
    Nginx|K&R|spaces|4|[code](https://trac.nginx.org/nginx/browser/nginx/src/core/nginx.c)
    LLVM (Apple/Google)|K&R|spaces|2|[code](https://github.com/llvm/llvm-project/blob/llvmorg-10.0.0/llvm/lib/Bitstream/Reader/BitstreamReader.cpp)
    @@ -275,9 +275,9 @@ Apache|K&R|spaces|4|[code](https://github.com/apache/httpd/blob/2.4.43/server/mp
    Firefox|K&R|spaces|2|[code](https://hg.mozilla.org/mozilla-central/raw-file/6256ec9113c1/dom/promise/Promise.cpp)
    Chromium (Google)|K&R|spaces|2|[code](https://chromium.googlesource.com/chromium/src.git/+/refs/tags/85.0.4178.1/ui/compositor/compositor.cc)
    LibreOffice|Allman|spaces|4|[code](https://cgit.freedesktop.org/libreoffice/core/tree/formula/source/ui/dlg/formula.cxx?h=libreoffice-6.4.5.1&id=be964ce243d03404cfeed53d0487f5d6bd49c627)
    PHP|K&R|tabs|4|[code](https://github.com/php/php-src/blob/php-7.4.7/Zend/zend_string.c), [code 2](https://github.com/php/php-src/blob/php-7.4.7/Zend/zend_operators.c)
    PHP|K&R|tabs|?|[code](https://github.com/php/php-src/blob/php-7.4.7/Zend/zend_string.c), [code 2](https://github.com/php/php-src/blob/php-7.4.7/Zend/zend_operators.c)
    Vim|Allman|mixed|4|[code](https://github.com/vim/vim/blob/v8.2.1017/src/edit.c), [code 2](https://github.com/vim/vim/blob/v8.2.1017/src/gui.c)
    Git|K&R|tabs|8|[CodingGuidelines](https://github.com/git/git/blob/v2.27.0/Documentation/CodingGuidelines), [code](https://github.com/git/git/blob/v2.27.0/send-pack.c)
    Git|K&R|tabs|?|[CodingGuidelines](https://github.com/git/git/blob/v2.27.0/Documentation/CodingGuidelines), [code](https://github.com/git/git/blob/v2.27.0/send-pack.c)

    Why does what other projects do matter? Only for familiarity. Switching between code written in different styles can be jarring. With most code having been written in K&R, the code you write will feel more familiar to others and others' code will feel more familiar to you by sharing the style.

  3. jesseschalken revised this gist Jun 28, 2020. 1 changed file with 1 addition and 1 deletion.
    2 changes: 1 addition & 1 deletion code_style.md
    View file
    Original file line number Diff line number Diff line change
    @@ -259,7 +259,7 @@ Phabricator (Facebook)|K&R|spaces|2|[Phabricator coding standards](https://secur
    .NET CLR (Microsoft)|Allman|spaces|4|[code](https://github.com/dotnet/coreclr/blob/v3.1.5/src/gcinfo/gcinfodumper.cpp)
    C# Guidelines (Microsoft)|Allman|spaces|4|[link](https://msdn.microsoft.com/en-us/library/vstudio/ff926074.aspx)
    TypeScript (Microsoft)|K&R|spaces|4|[code](https://github.com/microsoft/TypeScript/blob/v3.9.5/src/compiler/core.ts)
    Visual Studio Code|K&R|tabs|4|[code](https://github.com/microsoft/vscode/blob/master/src/vs/platform/credentials/common/credentials.ts)
    Visual Studio Code (Microsoft)|K&R|tabs|4|[code](https://github.com/microsoft/vscode/blob/master/src/vs/platform/credentials/common/credentials.ts)
    Sun Java JRE/JDK (Oracle)|K&R|spaces|2|[code](http://hg.openjdk.java.net/jdk7/jdk7/hotspot/file/9b0ca45cd756/src/cpu/x86/vm/sharedRuntime_x86_64.cpp)
    Linux Kernel|K&R|tab|8|[Coding Style](https://www.kernel.org/doc/Documentation/CodingStyle)
    IntelliJ (JetBrains)|K&R|spaces|2|[code](https://github.com/JetBrains/intellij-community/blob/idea/202.4357.23/platform/lang-impl/src/com/intellij/ide/CopyPasteDelegator.java)
  4. jesseschalken revised this gist Jun 28, 2020. 1 changed file with 2 additions and 1 deletion.
    3 changes: 2 additions & 1 deletion code_style.md
    View file
    Original file line number Diff line number Diff line change
    @@ -259,6 +259,7 @@ Phabricator (Facebook)|K&R|spaces|2|[Phabricator coding standards](https://secur
    .NET CLR (Microsoft)|Allman|spaces|4|[code](https://github.com/dotnet/coreclr/blob/v3.1.5/src/gcinfo/gcinfodumper.cpp)
    C# Guidelines (Microsoft)|Allman|spaces|4|[link](https://msdn.microsoft.com/en-us/library/vstudio/ff926074.aspx)
    TypeScript (Microsoft)|K&R|spaces|4|[code](https://github.com/microsoft/TypeScript/blob/v3.9.5/src/compiler/core.ts)
    Visual Studio Code|K&R|tabs|4|[code](https://github.com/microsoft/vscode/blob/master/src/vs/platform/credentials/common/credentials.ts)
    Sun Java JRE/JDK (Oracle)|K&R|spaces|2|[code](http://hg.openjdk.java.net/jdk7/jdk7/hotspot/file/9b0ca45cd756/src/cpu/x86/vm/sharedRuntime_x86_64.cpp)
    Linux Kernel|K&R|tab|8|[Coding Style](https://www.kernel.org/doc/Documentation/CodingStyle)
    IntelliJ (JetBrains)|K&R|spaces|2|[code](https://github.com/JetBrains/intellij-community/blob/idea/202.4357.23/platform/lang-impl/src/com/intellij/ide/CopyPasteDelegator.java)
    @@ -274,7 +275,7 @@ Apache|K&R|spaces|4|[code](https://github.com/apache/httpd/blob/2.4.43/server/mp
    Firefox|K&R|spaces|2|[code](https://hg.mozilla.org/mozilla-central/raw-file/6256ec9113c1/dom/promise/Promise.cpp)
    Chromium (Google)|K&R|spaces|2|[code](https://chromium.googlesource.com/chromium/src.git/+/refs/tags/85.0.4178.1/ui/compositor/compositor.cc)
    LibreOffice|Allman|spaces|4|[code](https://cgit.freedesktop.org/libreoffice/core/tree/formula/source/ui/dlg/formula.cxx?h=libreoffice-6.4.5.1&id=be964ce243d03404cfeed53d0487f5d6bd49c627)
    PHP|K&R|tabs|8|[code](https://github.com/php/php-src/blob/php-7.4.7/Zend/zend_string.c), [code 2](https://github.com/php/php-src/blob/php-7.4.7/Zend/zend_operators.c)
    PHP|K&R|tabs|4|[code](https://github.com/php/php-src/blob/php-7.4.7/Zend/zend_string.c), [code 2](https://github.com/php/php-src/blob/php-7.4.7/Zend/zend_operators.c)
    Vim|Allman|mixed|4|[code](https://github.com/vim/vim/blob/v8.2.1017/src/edit.c), [code 2](https://github.com/vim/vim/blob/v8.2.1017/src/gui.c)
    Git|K&R|tabs|8|[CodingGuidelines](https://github.com/git/git/blob/v2.27.0/Documentation/CodingGuidelines), [code](https://github.com/git/git/blob/v2.27.0/send-pack.c)

  5. jesseschalken revised this gist Jun 20, 2020. 1 changed file with 1 addition and 1 deletion.
    2 changes: 1 addition & 1 deletion code_style.md
    View file
    Original file line number Diff line number Diff line change
    @@ -250,7 +250,7 @@ This is a survey of well known software projects and companies and their chosen
    Note that some codebases use K&R style for control structures but Allman style for classes and functions. These have been grouped under "K&R".

    Company/Project|Brace Style|Indent Type|Indent Size|Reference
    ----|----|---|---|---|---
    ----|----|---|---|---
    Google|K&R|spaces|2|[Google C++ style guide](https://google.github.io/styleguide/cppguide.html#Spaces_vs._Tabs), [Google Java style guide](https://google.github.io/styleguide/javaguide.html#s4.1-braces)
    V8 (JavaScript engine) (Google)|K&R|spaces|2|[code](https://chromium.googlesource.com/v8/v8.git/+/refs/tags/8.5.188/src/ast/ast.cc)
    HHVM (Facebook)|K&R|spaces|2|[HHVM guidelines](https://github.com/facebook/hhvm/blob/HHVM-4.62.0/hphp/doc/coding-conventions.md), [code](https://github.com/facebook/hhvm/blob/HHVM-4.62.0/hphp/runtime/ext/string/ext_string.cpp)
  6. jesseschalken revised this gist Jun 20, 2020. 1 changed file with 1 addition and 1 deletion.
    2 changes: 1 addition & 1 deletion code_style.md
    View file
    Original file line number Diff line number Diff line change
    @@ -175,7 +175,7 @@ function typeName(obj)
    }
    ```

    In the Allman case, the simple fact that the `obj.isBoo()` branch needs two statements instead of one has caused the number of lines for the body of that branch to be four times taller than the others!
    In the Allman case, the simple fact that the `obj.isBoo()` branch needs two statements instead of one has caused the number of lines for the body of that branch to be four times taller than the others.

    ### Meaningless lines

  7. jesseschalken revised this gist Jun 20, 2020. 1 changed file with 76 additions and 52 deletions.
    128 changes: 76 additions & 52 deletions code_style.md
    View file
    Original file line number Diff line number Diff line change
    @@ -5,18 +5,22 @@ My preferred code style is 2-space K&R. This is intended to provide a justificat
    K&R style has the following properties:

    1. Provides symmetric size (in terms of screen space consumed) between the opening and closing syntax of a clode block.
    2. Forces no empty/meaningless lines, thereby avoiding artificial distance between related things that should be together.
    3. Consumes the minimum vertical space while keeping the opening and closing syntax of the block on separate lines from the content.
    2. Forces no empty or meaningless lines, thereby avoiding artificial distance between related things that should be together.
    3. Consumes the minimum vertical space while keeping the opening and closing syntax of a block on separate lines from the content.

    ![K&R style geometry](https://i.imgur.com/VwX9Xv3.png)

    ### Symmetric size
    ### Symmetric block open and block close

    Symmetry in size is important because it provides a visual cue that two things are similar in effect/importance.

    For example, in written text, lines of a paragraph are the same space apart. The space between paragraphs is larger, but also the same between each. The space between subsections, sections and chapters are progressively larger still. The space between things indicates their relatedness, the size of the headings indicate how large of a topic change they introduce. All line spaces are the same, all paragraph breaks are the same size, all chapter headings sizes are the same, etc.

    Two subsequent statements in a program are related by one happening after the other, i.e. one directly inheriting the state of the previous. Within a control structure, the first statement inside the structure and the statement before the structure are less related than two sequential statements, and so the introducing line of the control structure increases the space between them, and specifies the different nature of their relationship. The finishing line has the opposite, but equivalent role. The opener transitions fully into a block and the closer transitions fully out. Their real effect on the meaning of the code above and below each of them is of the same magnitude, in opposite directions. In K&R, the space the opener and closer of a control structure occupy on the screen is equivalent, to reflect their equivalent importance in terms of effect on the meaning of the code above and below each.
    Two subsequent statements in a program are related by one happening after the other, i.e. one directly inheriting the state of the previous. Within a control structure (`if`, `for` etc), the first statement inside the body and the statement before the structure are less related than two sequential statements, and so the introducing line of the control structure increases the space between them, and specifies the different nature of their relationship (conditional, loop etc).

    The finishing line of a control structure has the opposite, but equivalent role. The opener transitions fully into a block and the closer transitions fully out. Their real effect on the meaning of the code above and below each of them is of the same magnitude but in opposite directions.

    In K&R, the space the opener and closer of a control structure occupy on the screen is equivalent (one line) to reflect their equivalent importance in terms of effect on the meaning of the code above and below each.

    ### Comparison

    @@ -33,9 +37,9 @@ Pico|![Pico](https://i.imgur.com/WtCTEXx.png)|❌|❌|❌
    Ratliff|![Ratliff](https://i.imgur.com/geIcPRX.png)|✔️|❌|✔️
    Lisp|![Lisp](https://i.imgur.com/iNymSrZ.png)|✔️|❌|❌

    ### Similarity to other syntax
    ### Consistency with other syntax

    Notice the parallel that results between a stand-alone C (or a C-style language) block,
    Notice the consistency that results between a stand-alone C (or a C-style language) block,

    ```js
    {
    @@ -89,7 +93,7 @@ some HTML/XML,
    </ul>
    ```

    and an array/object/dictionary literal (JSON, JavaScript, Python, PHP, Ruby...).
    and an array, object/struct or dictionary literal (JSON, JavaScript, Python, PHP, Ruby etc).

    ```js
    var things = [
    @@ -125,9 +129,9 @@ if foo():
    boo()
    ```

    Except for the lack of a finishing line, since a dedicated closer is not needed. The block is closed by returning to the previous indent.
    Except for the lack of a finishing line, since a dedicated closer is not needed (the block is closed by returning to the previous indent).

    It is also the same as a control structure lacking braces (if permitted by your code style):
    It is also the same as a control structure lacking braces, if permitted by your code style:

    ```js
    if (foo())
    @@ -138,7 +142,7 @@ if (foo()) {
    }
    ```

    This means that the presence/absence of braces has a less dramatic effect on the code's layout. Compare these code samples, for example:
    This means that the presence or absence of braces has a less dramatic effect on the code's layout. Compare these code samples, for example:

    ```js
    function typeName(obj) {
    @@ -171,11 +175,13 @@ function typeName(obj)
    }
    ```

    In the Allman case, the simple fact that the `obj.isBoo()` branch needs two statements instead of one has caused the number of lines for the body of that branch to be four times taller than the others!

    ### Meaningless lines

    Code in K&R style has no enforced meaningless lines. Each line tells the reader something they wouldn't otherwise know, and they can therefore progress from one line to the next gathering new information at each. Blank lines are not bad per se, since they are useful to group related items together, and so hitting a blank line is a signpost, like a paragraph or section break in a book, that the old topic ends and a new topic starts, but whether a blank line is applicable in any given context is entirely dependant _on_ that context, and so cannot be decided by the coding style. Under K&R, every blank line has a _purpose_, decided by the programmer, based on the context, to group related lines together.
    Code in K&R style has no artificial meaningless lines enforced by the style. Each line tells the reader something they wouldn't otherwise know, and they can therefore progress from line to line next gathering new information at each. Blank lines are not bad, since they are useful to group related lines together and seperate unrelated lines, and so hitting a blank line is a signpost, like a paragraph or section break in a book, that the old topic ends and a new topic starts, but whether a blank line is applicable in any given context is entirely dependant _on_ that context, and so cannot be decided by the coding style. Under K&R, every blank line has a _purpose_, decided by the programmer, based on the context, to convey some informaiton about the relatedless of each line.

    Here is an example of the consequence of forced meaningless lines:
    Here is an example of the consequence of meaningless lines being enforced by the Allman style:

    ```php
    $foos = array();
    @@ -185,9 +191,9 @@ foreach (getFoos() as $foo)
    }
    ```

    Under Allman style, a blank line separates the initialisation of `$foos` and the loop header from the loop body. The blank line implies that they are unrelated, when in fact they are. The whole set of code belongs to a single topic of "array of transformed $foos" which the Allman style has artificially inserted a topic break inside of.
    Here, a blank line separates the initialisation of `$foos` and the loop header from the loop body. The blank line implies that they are unrelated, when in fact they are. The whole set of code belongs to a single topic of "array of transformed `$foo`s", but the Allman style has artificially inserted a topic break in the middle of this.

    Under K&R, the whole code block can be properly treated as a single visual unit:
    Under K&R, the whole code block can be properly treated visually as a single topic:

    ```php
    $foos = array();
    @@ -198,11 +204,11 @@ foreach (getFoos() as $foo) {

    ### Vertical space

    K&R style minimises the amount of vertical space which the code consumes, while maintaining that the syntax of the control structure itself does not share lines with it's contents.
    K&R style minimises the amount of vertical space which the code consumes, while maintaining that the syntax of the control structure itself does not share lines with its contents.

    Ensuring the control structure doesn't share lines with it's content is important. Lines are the "boxes" or categories in which related syntax goes. In the case of a code block, all the syntax related to a given statement goes on the same line. This not only helps visual comprehension, but means line-wise operations (triple-click select line, delete line, cut line, duplicate line, source code diff etc.) are meaningful. With the Lisp-style bracing, for example, the last brace on the same line as the last statement means that the "delete line" operation cannot be used to delete the last statement, and adding a statement to the end of the block creates a "-1 lines +2 lines" diff instead of only "+1 lines".
    Ensuring a control structure doesn't share lines with its content is important. Lines are the "boxes" or categories in which related syntax goes. In the case of a code block, all the syntax related to a given statement goes on the same line. This not only helps visual comprehension, but means line-wise operations are meaningful (triple-click select line, delete line, cut line, duplicate line, source code diff etc). With the Lisp-style bracing, for example, the last brace on the same line as the last statement means that the "delete line" operation cannot be used to delete the last statement, and adding a statement to the end of the block creates a "-1 lines +2 lines" diff instead of a "+1 lines" diff.

    Ensuring the code minimises the amount of vertical space is important for information density, i.e. the total amount of information that is readily available, per unit of screen space. Minimising vertical space (lines) used helps the reader to get a "birds eye" view of the code without using a smaller font and without removing the indents and purposeful blank lines that give the code a visual structure. The more code that can be fit on screen without compromising it's visual structure, the more readily the code can be read.
    Ensuring the code minimises the amount of vertical space is important for information density, i.e. the total amount of information that is readily available, per unit of screen space. Minimising vertical space (lines) used helps the reader to get a "birds eye" view of the code without using a smaller font and without removing the indents and purposeful blank lines that give the code a visual structure. The more code that can be fit on screen without compromising its visual structure, the more readily the code can be read.

    Consider you have two statements:

    @@ -239,38 +245,38 @@ Under K&R, the overhead in consumed lines for each control structure is 2. In Al

    ### Survey

    This is a survey of well known software projects/companies and their brace/indent style.
    This is a survey of well known software projects and companies and their chosen brace and indent style.

    Note that some codebases use K&R style for control structures but Allman style for classes and functions. These have been grouped under "K&R".

    Company/Project|Brace Style|Indent Type|Indent Size|Spaces inside<br>`(` `)`?|Reference
    Company/Project|Brace Style|Indent Type|Indent Size|Reference
    ----|----|---|---|---|---
    Google|K&R|spaces|2|no<br>(allowed)|[Google C++ style guide](https://google-styleguide.googlecode.com/svn/trunk/cppguide.html#Conditionals), [Google Java style guide](https://google.github.io/styleguide/javaguide.html)
    V8 (JavaScript engine) (Google)|K&R|spaces|2|no|[code](https://chromium.googlesource.com/v8/v8.git/+/master/src/ast-expression-visitor.cc)
    HHVM (Facebook)|K&R|spaces|2|no|[HHVM guidelines](https://github.com/facebook/hhvm/blob/master/hphp/doc/coding-conventions.md), see also [code](https://github.com/facebook/hhvm/blob/master/hphp/runtime/ext/string/ext_string.cpp)
    Proxygen (Facebook)|K&R|spaces|2|no|[code](https://github.com/facebook/proxygen/blob/master/proxygen/lib/http/HTTPMessage.cpp)
    Phabricator (Facebook)|K&R|spaces|2|no|[Phabricator coding standards](https://secure.phabricator.com/book/phabcontrib/article/php_coding_standards/)
    .NET CLR (Microsoft)|Allman|spaces|4|no|[code](https://github.com/dotnet/coreclr/blob/master/src/gcinfo/gcinfodumper.cpp)
    C# Guidelines (Microsoft)|Allman|spaces|4|no|[link](https://msdn.microsoft.com/en-us/library/vstudio/ff926074.aspx)
    TypeScript (Microsoft)|K&R|spaces|4|no|[code](https://github.com/Microsoft/TypeScript/blob/master/src/compiler/core.ts)
    Sun Java JRE/JDK (Oracle)|K&R|spaces|2|no|[code](http://hg.openjdk.java.net/jdk7/jdk7/hotspot/file/9b0ca45cd756/src/cpu/x86/vm/sharedRuntime_x86_64.cpp)
    Linux Kernel|K&R|tab|8|no|[Coding Style](https://www.kernel.org/doc/Documentation/CodingStyle)
    IntelliJ (JetBrains)|K&R|spaces|2|no|[code](https://github.com/JetBrains/intellij-community/blob/master/platform/lang-impl/src/com/intellij/ide/CopyPasteDelegator.java)
    Nginx|K&R|spaces|4|no|[code](https://trac.nginx.org/nginx/browser/nginx/src/core/nginx.c)
    LLVM|K&R|spaces|2|no|[code](https://github.com/llvm-mirror/llvm/blob/master/lib/IR/LLVMContext.cpp)
    JavaScriptCore (Apple)|K&R|spaces|4|no|[code](http://www.opensource.apple.com/source/JavaScriptCore/JavaScriptCore-7600.8.7/bytecompiler/BytecodeGenerator.cpp)
    WebCore (Apple)|K&R|spaces|4|no|[code](http://www.opensource.apple.com/source/WebCore/WebCore-7600.8.9/history/CachedFrame.cpp)
    SystemD (RedHat)|K&R|spaces|8|no|[code](https://github.com/systemd/systemd/blob/master/src/libsystemd/sd-event/sd-event.c)
    KDE|K&R|spaces|4|no|[code](https://projects.kde.org/projects/kde/applications/dolphin/repository/revisions/master/entry/src/dolphinpart.cpp)
    GNOME|K&R|spaces|8|no|[code](https://git.gnome.org/browse/gnome-settings-daemon/tree/gnome-settings-daemon/gnome-settings-manager.c)
    RequireJS|K&R|spaces|4|no|[code](https://github.com/jrburke/requirejs/blob/master/require.js)
    Apache|K&R|spaces|4|no|[code](https://github.com/apache/httpd/blob/trunk/server/mpm/worker/worker.c)
    Firefox|K&R|spaces|2|no|[code](https://hg.mozilla.org/mozilla-central/raw-file/6256ec9113c1/dom/promise/Promise.cpp)
    Chromium (Google)|K&R|spaces|2|no|[code](https://chromium.googlesource.com/chromium/src.git/+/master/ui/compositor/compositor.cc)
    LibreOffice|Allman|spaces|4|no|[code](http://cgit.freedesktop.org/libreoffice/core/tree/formula/source/ui/dlg/formula.cxx)
    PHP|K&R|tabs|8|no|[code](https://github.com/php/php-src/blob/master/Zend/zend_string.c), [code 2](https://github.com/php/php-src/blob/master/Zend/zend_operators.c)
    Vim|Allman|mixed|4|no|[code](https://github.com/vim/vim/blob/master/src/edit.c), [code 2](https://github.com/vim/vim/blob/master/src/gui.c)
    Git|K&R|tabs|8|no|[CodingGuidelines](https://github.com/git/git/blob/master/Documentation/CodingGuidelines), [code](https://github.com/git/git/blob/master/send-pack.c)
    Google|K&R|spaces|2|[Google C++ style guide](https://google.github.io/styleguide/cppguide.html#Spaces_vs._Tabs), [Google Java style guide](https://google.github.io/styleguide/javaguide.html#s4.1-braces)
    V8 (JavaScript engine) (Google)|K&R|spaces|2|[code](https://chromium.googlesource.com/v8/v8.git/+/refs/tags/8.5.188/src/ast/ast.cc)
    HHVM (Facebook)|K&R|spaces|2|[HHVM guidelines](https://github.com/facebook/hhvm/blob/HHVM-4.62.0/hphp/doc/coding-conventions.md), [code](https://github.com/facebook/hhvm/blob/HHVM-4.62.0/hphp/runtime/ext/string/ext_string.cpp)
    Proxygen (Facebook)|K&R|spaces|2|[code](https://github.com/facebook/proxygen/blob/v2020.06.15.00/proxygen/lib/http/HTTPMessage.cpp)
    Phabricator (Facebook)|K&R|spaces|2|[Phabricator coding standards](https://secure.phabricator.com/book/phabcontrib/article/php_coding_standards/)
    .NET CLR (Microsoft)|Allman|spaces|4|[code](https://github.com/dotnet/coreclr/blob/v3.1.5/src/gcinfo/gcinfodumper.cpp)
    C# Guidelines (Microsoft)|Allman|spaces|4|[link](https://msdn.microsoft.com/en-us/library/vstudio/ff926074.aspx)
    TypeScript (Microsoft)|K&R|spaces|4|[code](https://github.com/microsoft/TypeScript/blob/v3.9.5/src/compiler/core.ts)
    Sun Java JRE/JDK (Oracle)|K&R|spaces|2|[code](http://hg.openjdk.java.net/jdk7/jdk7/hotspot/file/9b0ca45cd756/src/cpu/x86/vm/sharedRuntime_x86_64.cpp)
    Linux Kernel|K&R|tab|8|[Coding Style](https://www.kernel.org/doc/Documentation/CodingStyle)
    IntelliJ (JetBrains)|K&R|spaces|2|[code](https://github.com/JetBrains/intellij-community/blob/idea/202.4357.23/platform/lang-impl/src/com/intellij/ide/CopyPasteDelegator.java)
    Nginx|K&R|spaces|4|[code](https://trac.nginx.org/nginx/browser/nginx/src/core/nginx.c)
    LLVM (Apple/Google)|K&R|spaces|2|[code](https://github.com/llvm/llvm-project/blob/llvmorg-10.0.0/llvm/lib/Bitstream/Reader/BitstreamReader.cpp)
    JavaScriptCore (Apple)|K&R|spaces|4|[code](http://www.opensource.apple.com/source/JavaScriptCore/JavaScriptCore-7600.8.7/bytecompiler/BytecodeGenerator.cpp)
    WebCore (Apple)|K&R|spaces|4|[code](http://www.opensource.apple.com/source/WebCore/WebCore-7600.8.9/history/CachedFrame.cpp)
    SystemD (RedHat)|K&R|spaces|8|[code](https://github.com/systemd/systemd/blob/v245/src/libsystemd/sd-event/sd-event.c)
    KDE|K&R|spaces|4|[code](https://invent.kde.org/system/dolphin/-/blob/v20.04.2/src/dolphinpart.cpp)
    GNOME|GNU, K&R|mixed|2, 4|[C code](https://gitlab.gnome.org/GNOME/gvfs/-/blob/master/common/gmounttracker.c), [JS code](https://gitlab.gnome.org/GNOME/gnome-shell/-/blob/master/js/ui/layout.js), [Vala code](https://gitlab.gnome.org/GNOME/vala/-/blob/master/vala/valaaddressofexpression.vala)
    RequireJS|K&R|spaces|4|[code](https://github.com/requirejs/requirejs/blob/2.3.6/require.js)
    Apache|K&R|spaces|4|[code](https://github.com/apache/httpd/blob/2.4.43/server/mpm/worker/worker.c)
    Firefox|K&R|spaces|2|[code](https://hg.mozilla.org/mozilla-central/raw-file/6256ec9113c1/dom/promise/Promise.cpp)
    Chromium (Google)|K&R|spaces|2|[code](https://chromium.googlesource.com/chromium/src.git/+/refs/tags/85.0.4178.1/ui/compositor/compositor.cc)
    LibreOffice|Allman|spaces|4|[code](https://cgit.freedesktop.org/libreoffice/core/tree/formula/source/ui/dlg/formula.cxx?h=libreoffice-6.4.5.1&id=be964ce243d03404cfeed53d0487f5d6bd49c627)
    PHP|K&R|tabs|8|[code](https://github.com/php/php-src/blob/php-7.4.7/Zend/zend_string.c), [code 2](https://github.com/php/php-src/blob/php-7.4.7/Zend/zend_operators.c)
    Vim|Allman|mixed|4|[code](https://github.com/vim/vim/blob/v8.2.1017/src/edit.c), [code 2](https://github.com/vim/vim/blob/v8.2.1017/src/gui.c)
    Git|K&R|tabs|8|[CodingGuidelines](https://github.com/git/git/blob/v2.27.0/Documentation/CodingGuidelines), [code](https://github.com/git/git/blob/v2.27.0/send-pack.c)

    Why does what other projects do matter? Only for familiarity. Switching between code written in different styles can be jarring. With most code having been written in K&R, the code you write will feel more familiar to others and others' code will feel more familiar to you by sharing the style.

    @@ -289,17 +295,35 @@ The requirement of #2, that all software displaying the code be configured to ha

    Not to mention code samples that are put in emails, chat messages, code review/bug tracker issues/comments, blog posts and presentation slides.

    Each tool will have it's own default display size for a tab (usually 8) and each tool may or may not let you change it. GitHub, for example, renders tabs with 8 spaces, which can only temporarily be changed by adding `?ts=...` to the URL and reloading the page. Consequently, using tabs, you are destined to find yourself reading your code with the wrong indent size (usually 8), whether you like it or not, and depending on the tool, you may not be able to do anything about it. It is not possible to impose the requirement of user-configurable tab sizes on all the software which happens to render your code.
    Each tool will have its own default display size for a tab (usually 8) and each tool may or may not let you change it. GitHub, for example, renders tabs with 8 spaces, which can only temporarily be changed by adding `?ts=...` to the URL and reloading the page. Consequently, using tabs, you are destined to find yourself reading your code with the wrong indent size (usually 8), whether you like it or not, and depending on the tool, you may not be able to do anything about it.

    It is simply not possible to impose the requirement of user-configurable tab sizes on all the software which happens to render your code.

    Spaces impose no such requirement. By embedding the correct indent size directly in the code, the code is rendered correctly everywhere, even if you cut and paste it into an email.

    ## Why *2* spaces?

    Spaces impose no such requirement. By embedding the correct tab size directly in the code, the code is rendered correctly everywhere, even if you cut and paste it into an email.
    Characters in most monospace fonts are approximately twice as high as they are wide, and as such a 2 space indent is approximately the same width as the height of a blank line. If a blank line is the correct size for grouping and spacing things vertically, then it follows that 2 spaces should be appriximately the correct size for groping and spacing things horizontally.

    ## Why 2 spaces?
    This also means that a line that follows the lead of nested control structures and the line of closing braces are both at a 45° angle.

    ```js
    function foo() {
    if (bar) {
    while (baz) {
    if (zap) {
    return zoo;
    // ↖ this line has a 45° angle to "function foo() {"
    // ↙ line of closing braces is also at a 45° angle
    }
    }
    }
    }
    ```

    So what should the tab size be? The size is a balance between:
    - Giving the indent a big enough "kick" so that the structure of the code pops out.
    - Keeping the first indented line close enough to the line that introduced it so as not to disrupt the flow of reading.
    2 spaces is also the minimum possible indent size that is larger than the individual spaces that are used to separate words within a line.

    For this purpose, 2 or 4 is reasonable and common. I find 2 spaces to be preferrable because it conserves horizontal real estate and often provides a near symmetry between the height of a line and the side of an indent.
    2 spaces conserves more horizontal space than the alternative 4 or 8 spaces. This is important because just as there is a cost in vertical space, there is a cost in horizontal space. The higher the indent size, the less horizontal space the body of a control structure has between the indent on the left and the margin on the right. Deeply nested control structures (which *are* sometimes appropriate) become more feasible the smaller the indent.

    From Steve McConnell's Code Complete Second Edition chapter on Layout and Style:

  8. jesseschalken revised this gist Jun 18, 2020. 1 changed file with 1 addition and 1 deletion.
    2 changes: 1 addition & 1 deletion code_style.md
    View file
    Original file line number Diff line number Diff line change
    @@ -8,7 +8,7 @@ K&R style has the following properties:
    2. Forces no empty/meaningless lines, thereby avoiding artificial distance between related things that should be together.
    3. Consumes the minimum vertical space while keeping the opening and closing syntax of the block on separate lines from the content.

    ![K&R style geometry](https://i.imgur.com/EWqCbAM.png)
    ![K&R style geometry](https://i.imgur.com/VwX9Xv3.png)

    ### Symmetric size

  9. jesseschalken revised this gist Jun 18, 2020. 1 changed file with 8 additions and 8 deletions.
    16 changes: 8 additions & 8 deletions code_style.md
    View file
    Original file line number Diff line number Diff line change
    @@ -24,14 +24,14 @@ Here is a comparison of brace styles found on [Wikipedia](https://en.wikipedia.o

    Name|Example|Open/close<br>equal height|Open/close<br>equal indent|Open/close<br>don't share<br>lines with<br>content
    -----|-----|:----:|:----:|:-----:
    K&R|![K&R](https://i.imgur.com/v16hhIn.png)|✔|✔|✔
    Allman|![Allman](https://i.imgur.com/b6YACVR.png)|✘|✔|✔
    GNU|![GNU](https://i.imgur.com/p7aPVhL.png)|✘|✘|✔
    Whitesmiths|![Whitesmits](https://i.imgur.com/soHPavi.png)|✘|✘|✔
    Horstmann|![Horstmann](https://i.imgur.com/iMhsql4.png)|✘|✔|✘
    Pico|![Pico](https://i.imgur.com/WtCTEXx.png)|✘|✘|✘
    Ratliff|![Ratliff](https://i.imgur.com/geIcPRX.png)|✔|✘|✔
    Lisp|![Lisp](https://i.imgur.com/iNymSrZ.png)|✔|✘|✘
    K&R|![K&R](https://i.imgur.com/v16hhIn.png)|✔️|✔️|✔️
    Allman|![Allman](https://i.imgur.com/b6YACVR.png)|❌|✔️|✔️
    GNU|![GNU](https://i.imgur.com/p7aPVhL.png)|❌|❌|✔️
    Whitesmiths|![Whitesmits](https://i.imgur.com/soHPavi.png)|❌|❌|✔️
    Horstmann|![Horstmann](https://i.imgur.com/iMhsql4.png)|❌|✔️|❌
    Pico|![Pico](https://i.imgur.com/WtCTEXx.png)|❌|❌|❌
    Ratliff|![Ratliff](https://i.imgur.com/geIcPRX.png)|✔️|❌|✔️
    Lisp|![Lisp](https://i.imgur.com/iNymSrZ.png)|✔️|❌|❌

    ### Similarity to other syntax

  10. jesseschalken revised this gist Jun 18, 2020. 1 changed file with 8 additions and 57 deletions.
    65 changes: 8 additions & 57 deletions code_style.md
    View file
    Original file line number Diff line number Diff line change
    @@ -24,14 +24,14 @@ Here is a comparison of brace styles found on [Wikipedia](https://en.wikipedia.o

    Name|Example|Open/close<br>equal height|Open/close<br>equal indent|Open/close<br>don't share<br>lines with<br>content
    -----|-----|:----:|:----:|:-----:
    K&R|![K&R](https://i.imgur.com/yxbzDbj.png)|✔|✔|✔
    Allman|![Allman](https://i.imgur.com/hwTmIAf.png)|✘|✔|✔
    GNU|![GNU](https://i.imgur.com/UQtTt04.png)|✘|✘|✔
    Whitesmiths|![Whitesmits](https://i.imgur.com/mxkQWdP.png)|✘|✘|✔
    Horstmann|![Horstmann](https://i.imgur.com/Py4p9GM.png)|✘|✔|✘
    Pico|![Pico](https://i.imgur.com/QJeXkGn.png)|✘|✘|✘
    Ratliff|![Ratliff](https://i.imgur.com/exYXuiR.png)|✔|✘|✔
    Lisp|![Lisp](https://i.imgur.com/zixYwi5.png)|✔|✘|✘
    K&R|![K&R](https://i.imgur.com/v16hhIn.png)|✔|✔|✔
    Allman|![Allman](https://i.imgur.com/b6YACVR.png)|✘|✔|✔
    GNU|![GNU](https://i.imgur.com/p7aPVhL.png)|✘|✘|✔
    Whitesmiths|![Whitesmits](https://i.imgur.com/soHPavi.png)|✘|✘|✔
    Horstmann|![Horstmann](https://i.imgur.com/iMhsql4.png)|✘|✔|✘
    Pico|![Pico](https://i.imgur.com/WtCTEXx.png)|✘|✘|✘
    Ratliff|![Ratliff](https://i.imgur.com/geIcPRX.png)|✔|✘|✔
    Lisp|![Lisp](https://i.imgur.com/iNymSrZ.png)|✔|✘|✘

    ### Similarity to other syntax

    @@ -305,52 +305,3 @@ From Steve McConnell's Code Complete Second Edition chapter on Layout and Style:

    > Subjects scored 20 to 30 percent higher on a test of comprehension when programs had a two-to-four-spaces indentation scheme than they did when programs had no indentation at all. The same study found that it was important to neither under-emphasize nor over emphasize a program’s logical structure. The lowest comprehension scores were achieved on programs that were not indented at all. The second lowest were achieved on programs that used six-space indentation. The study concluded that two-to-four-space indentation was optimal. Interestingly, many subjects in the experiment felt that the six-space indentation was easier to use than the smaller indentations, even though their scores were lower. That’s probably because six space indentation looks pleasing. But regardless of how pretty it looks, six-space indentation turns out to be less readable. This is an example of a collision be tween aesthetic appeal and readability.
    ## Class member ordering

    Class members can be classified along four different dimensions:
    - Type (constant, property, constructor, method)
    - Staticness (static, non-static)
    - Visibility (public, protected, private)
    - Abstrction (final, non-final, abstract)

    All else being equal, class members should be sorted in the order of: staticness, type, visibility, abstraction. For example:

    ```php
    abstract class Foo {
    use Trait1;

    // static members

    const _1 = 0;

    static public $_1;
    static protected $_2;
    static private $_3;

    static public final function _1() {}
    static public function _2() {}
    static protected final function _3() {}
    static protected function _4() {}
    static private function _5() {}

    // instance members

    public $_4;
    protected $_5;
    private $_6;

    public function __construct() {}

    public final function _6() {}
    public function _7() {}
    public abstract function _8();

    protected final function _9() {}
    protected function _10() {}
    protected abstract function _11();

    private function _12() {}
    }
    ```

    It is permissable to use a different ordering if the circumstances favour it. For example, a very large class may be more easily navigated with members arranged by topic. (However a class of that size should probably be split up where possible.)
  11. jesseschalken revised this gist May 9, 2020. 1 changed file with 9 additions and 9 deletions.
    18 changes: 9 additions & 9 deletions code_style.md
    View file
    Original file line number Diff line number Diff line change
    @@ -8,7 +8,7 @@ K&R style has the following properties:
    2. Forces no empty/meaningless lines, thereby avoiding artificial distance between related things that should be together.
    3. Consumes the minimum vertical space while keeping the opening and closing syntax of the block on separate lines from the content.

    ![K&R style geometry](http://oi57.tinypic.com/2jczm9k.jpg)
    ![K&R style geometry](https://i.imgur.com/EWqCbAM.png)

    ### Symmetric size

    @@ -24,14 +24,14 @@ Here is a comparison of brace styles found on [Wikipedia](https://en.wikipedia.o

    Name|Example|Open/close<br>equal height|Open/close<br>equal indent|Open/close<br>don't share<br>lines with<br>content
    -----|-----|:----:|:----:|:-----:
    K&R|![K&R](http://i58.tinypic.com/ej6g0.png)|✔|✔|✔
    Allman|![Allman](http://oi58.tinypic.com/yovf9.jpg)|✘|✔|✔
    GNU|![GNU](http://i59.tinypic.com/sy8mle.png)|✘|✘|✔
    Whitesmiths|![Whitesmits](http://i58.tinypic.com/9zrsw3.png)|✘|✘|✔
    Horstmann|![Horstmann](http://i60.tinypic.com/z8jsl.png)|✘|✔|✘
    Pico|![Pico](http://i60.tinypic.com/1hqg07.png)|✘|✘|✘
    Ratliff|![Ratliff](http://i59.tinypic.com/30hsfvq.png)|✔|✘|✔
    Lisp|![Lisp](http://i58.tinypic.com/2dbqm43.png)|✔|✘|✘
    K&R|![K&R](https://i.imgur.com/yxbzDbj.png)|✔|✔|✔
    Allman|![Allman](https://i.imgur.com/hwTmIAf.png)|✘|✔|✔
    GNU|![GNU](https://i.imgur.com/UQtTt04.png)|✘|✘|✔
    Whitesmiths|![Whitesmits](https://i.imgur.com/mxkQWdP.png)|✘|✘|✔
    Horstmann|![Horstmann](https://i.imgur.com/Py4p9GM.png)|✘|✔|✘
    Pico|![Pico](https://i.imgur.com/QJeXkGn.png)|✘|✘|✘
    Ratliff|![Ratliff](https://i.imgur.com/exYXuiR.png)|✔|✘|✔
    Lisp|![Lisp](https://i.imgur.com/zixYwi5.png)|✔|✘|✘

    ### Similarity to other syntax

  12. jesseschalken revised this gist Jun 6, 2017. 1 changed file with 8 additions and 6 deletions.
    14 changes: 8 additions & 6 deletions code_style.md
    View file
    Original file line number Diff line number Diff line change
    @@ -173,7 +173,7 @@ function typeName(obj)

    ### Meaningless lines

    Code in K&R style has no enforced meaningless lines. Each line tells the reader something they wouldn't otherwise know, and they can therefore progress from one line to the next gathering new information at each. Meaningless lines are not bad _per se_. Blank lines can be useful to group related items together, and so hitting a blank line is a signpost, like a paragraph or section break in a book, that the old topic ends and a new topic starts, but whether a blank/meaningless line is applicable in any given context is entirely dependant _on_ that context, and so cannot be decided by the coding style. Under K&R, every blank line has a _purpose_, decided by the programmer, based on the context, to group related lines together.
    Code in K&R style has no enforced meaningless lines. Each line tells the reader something they wouldn't otherwise know, and they can therefore progress from one line to the next gathering new information at each. Blank lines are not bad per se, since they are useful to group related items together, and so hitting a blank line is a signpost, like a paragraph or section break in a book, that the old topic ends and a new topic starts, but whether a blank line is applicable in any given context is entirely dependant _on_ that context, and so cannot be decided by the coding style. Under K&R, every blank line has a _purpose_, decided by the programmer, based on the context, to group related lines together.

    Here is an example of the consequence of forced meaningless lines:

    @@ -200,7 +200,7 @@ foreach (getFoos() as $foo) {

    K&R style minimises the amount of vertical space which the code consumes, while maintaining that the syntax of the control structure itself does not share lines with it's contents.

    Ensuring the control structure doesn't share lines with it's content is important. Lines are the "boxes" or categories in which related syntax goes. In the case of a code block, all the syntax related to a given statement goes on the same line. This not only helps visual comprehension, but means line-wise operations (triple-click select line, delete line, cut line, duplicate line, source code diff etc.) are meaningful. With the Lisp-style bracing, for example, the last brace on the same line as the last statement means that the "delete line" operation cannot be used to delete the last statement, and adding a statement to the end of the block creates a "-1 lines +2 lines" diff instead of simply "+1 lines".
    Ensuring the control structure doesn't share lines with it's content is important. Lines are the "boxes" or categories in which related syntax goes. In the case of a code block, all the syntax related to a given statement goes on the same line. This not only helps visual comprehension, but means line-wise operations (triple-click select line, delete line, cut line, duplicate line, source code diff etc.) are meaningful. With the Lisp-style bracing, for example, the last brace on the same line as the last statement means that the "delete line" operation cannot be used to delete the last statement, and adding a statement to the end of the block creates a "-1 lines +2 lines" diff instead of only "+1 lines".

    Ensuring the code minimises the amount of vertical space is important for information density, i.e. the total amount of information that is readily available, per unit of screen space. Minimising vertical space (lines) used helps the reader to get a "birds eye" view of the code without using a smaller font and without removing the indents and purposeful blank lines that give the code a visual structure. The more code that can be fit on screen without compromising it's visual structure, the more readily the code can be read.

    @@ -235,7 +235,7 @@ for (...; ...; ...)
    }
    ```

    Under K&R, the overhead in consumed lines for each control structure is 2. In Allman the overhead is 3, i.e. a 50% higher "cost" in vertical space.
    Under K&R, the overhead in consumed lines for each control structure is 2. In Allman the overhead is 3, i.e. a 50% higher cost in vertical space.

    ### Survey

    @@ -274,7 +274,7 @@ Git|K&R|tabs|8|no|[CodingGuidelines](https://github.com/git/git/blob/master/Docu

    Why does what other projects do matter? Only for familiarity. Switching between code written in different styles can be jarring. With most code having been written in K&R, the code you write will feel more familiar to others and others' code will feel more familiar to you by sharing the style.

    ## Why 4 spaces?
    ## Why spaces?

    1. The good thing about tabs is that each person _can_ configure their tools to render tabs using their preferred size.
    2. The bad thing about tabs is that each person _must_ configure their tools to render tabs using their preferred size.
    @@ -293,11 +293,13 @@ Each tool will have it's own default display size for a tab (usually 8) and each

    Spaces impose no such requirement. By embedding the correct tab size directly in the code, the code is rendered correctly everywhere, even if you cut and paste it into an email.

    ## Why 2 spaces?

    So what should the tab size be? The size is a balance between:
    - Giving the indent a big enough "kick" so that the structure of the code pops out.
    - Keeping the first indented line close enough to the line that introduced it so as not to disrupt the flow of reading.

    For this purpose, 2 or 4 is reasonable and common. I find 4 spaces to be a nice balance. 8 seems to throw your code to the other side of the screen. 2 seems to reduce the indentation silhouette to nothing more than a wobbly line.
    For this purpose, 2 or 4 is reasonable and common. I find 2 spaces to be preferrable because it conserves horizontal real estate and often provides a near symmetry between the height of a line and the side of an indent.

    From Steve McConnell's Code Complete Second Edition chapter on Layout and Style:

    @@ -351,4 +353,4 @@ abstract class Foo {
    }
    ```

    It is permissable to use a different ordering if the circumstances favour it. For example, a very large class may be more easily navigated with members arranged by topic.
    It is permissable to use a different ordering if the circumstances favour it. For example, a very large class may be more easily navigated with members arranged by topic. (However a class of that size should probably be split up where possible.)
  13. jesseschalken revised this gist Jun 6, 2017. 1 changed file with 77 additions and 77 deletions.
    154 changes: 77 additions & 77 deletions code_style.md
    View file
    Original file line number Diff line number Diff line change
    @@ -1,4 +1,4 @@
    My preferred code style is 4-space K&R. This is intended to provide a justification for this style.
    My preferred code style is 2-space K&R. This is intended to provide a justification for this style.

    ## Why K&R?

    @@ -39,77 +39,77 @@ Notice the parallel that results between a stand-alone C (or a C-style language)

    ```js
    {
    foo();
    bar();
    foo();
    bar();
    }
    ```

    an `if` block in C (or a C-style language) (K&R style),

    ```js
    if (x == y) {
    foo();
    bar();
    foo();
    bar();
    }
    ```

    a PHP block-style `if` block,

    ```php
    if (x == y):
    foo();
    bar();
    foo();
    bar();
    endif;
    ```

    a Ruby `if` block,

    ```ruby
    if x == y
    foo()
    bar()
    foo()
    bar()
    end
    ```

    an `if` block in the Fish shell,

    ```fish
    if x == y
    foo
    bar
    foo
    bar
    end
    ```

    some HTML/XML,

    ```xml
    <ul style="...">
    <li>foo</li>
    <li>bar</li>
    <li>foo</li>
    <li>bar</li>
    </ul>
    ```

    and an array/object/dictionary literal (JSON, JavaScript, Python, PHP, Ruby...).

    ```js
    var things = [
    'foo',
    'bar',
    'foo',
    'bar',
    ];
    ```

    ```js
    var things = {
    foo: 'foo',
    bar: 'bar',
    foo: 'foo',
    bar: 'bar',
    };
    ```

    All of these follow a simple pattern:

    ```
    (introducer)
    (entries)
    (entries)
    (finisher)
    ```

    @@ -119,8 +119,8 @@ The visual relationship between the opener of the block and it's contents is als

    ```python
    if foo():
    bar()
    baz()
    bar()
    baz()

    boo()
    ```
    @@ -131,43 +131,43 @@ It is also the same as a control structure lacking braces (if permitted by your

    ```js
    if (foo())
    bar();
    bar();

    if (foo()) {
    bar();
    bar();
    }
    ```

    This means that the presence/absence of braces has a less dramatic effect on the code's layout. Compare these code samples, for example:

    ```js
    function typeName(obj) {
    if (obj.isFoo())
    return 'foo';
    else if (obj.isBar())
    return 'bar';
    else if (obj.isBoo()) {
    log_notice('Cannot get name of a boo');
    return null;
    } else
    throw new Error();
    if (obj.isFoo())
    return 'foo';
    else if (obj.isBar())
    return 'bar';
    else if (obj.isBoo()) {
    log_notice('Cannot get name of a boo');
    return null;
    } else
    throw new Error();
    }
    ```

    ```js
    function typeName(obj)
    {
    if (obj.isFoo())
    return 'foo';
    else if (obj.isBar())
    return 'bar';
    else if (obj.isBoo())
    {
    log_notice('Cannot get name of a boo');
    return null;
    }
    else
    throw new Error();
    if (obj.isFoo())
    return 'foo';
    else if (obj.isBar())
    return 'bar';
    else if (obj.isBoo())
    {
    log_notice('Cannot get name of a boo');
    return null;
    }
    else
    throw new Error();
    }
    ```

    @@ -181,7 +181,7 @@ Here is an example of the consequence of forced meaningless lines:
    $foos = array();
    foreach (getFoos() as $foo)
    {
    $foos[] = transformFoo($foo);
    $foos[] = transformFoo($foo);
    }
    ```

    @@ -192,7 +192,7 @@ Under K&R, the whole code block can be properly treated as a single visual unit:
    ```php
    $foos = array();
    foreach (getFoos() as $foo) {
    $foos[] = transformFoo($foo);
    $foos[] = transformFoo($foo);
    }
    ```

    @@ -215,10 +215,10 @@ and you want to wrap them in a `if` block wrapped by a `for` loop. The K&R resul

    ```js
    for (...; ...; ...) {
    if (...) {
    foo();
    bar();
    }
    if (...) {
    foo();
    bar();
    }
    }
    ```

    @@ -227,11 +227,11 @@ While the Allman result is:
    ```js
    for (...; ...; ...)
    {
    if (...)
    {
    foo();
    bar();
    }
    if (...)
    {
    foo();
    bar();
    }
    }
    ```

    @@ -301,7 +301,7 @@ For this purpose, 2 or 4 is reasonable and common. I find 4 spaces to be a nice

    From Steve McConnell's Code Complete Second Edition chapter on Layout and Style:

    > Subjects scored 20 to 30 percent higher on a test of comprehension when programs had a two-to-four-spaces indentation scheme than they did when programs had no indentation at all.The same study found that it was important to neither under-emphasize nor over emphasize a program’s logical structure. The lowest comprehension scores were achieved on programs that were not indented at all. The second lowest were achieved on programs that used six-space indentation. The study concluded that two-to-four-space indentation was optimal. Interestingly, many subjects in the experiment felt that the six-space indentation was easier to use than the smaller indentations, even though their scores were lower. That’s probably because six space indentation looks pleasing. But regardless of how pretty it looks, six-space indentation turns out to be less readable. This is an example of a collision be tween aesthetic appeal and readability.
    > Subjects scored 20 to 30 percent higher on a test of comprehension when programs had a two-to-four-spaces indentation scheme than they did when programs had no indentation at all. The same study found that it was important to neither under-emphasize nor over emphasize a program’s logical structure. The lowest comprehension scores were achieved on programs that were not indented at all. The second lowest were achieved on programs that used six-space indentation. The study concluded that two-to-four-space indentation was optimal. Interestingly, many subjects in the experiment felt that the six-space indentation was easier to use than the smaller indentations, even though their scores were lower. That’s probably because six space indentation looks pleasing. But regardless of how pretty it looks, six-space indentation turns out to be less readable. This is an example of a collision be tween aesthetic appeal and readability.
    ## Class member ordering

    @@ -315,39 +315,39 @@ All else being equal, class members should be sorted in the order of: staticness

    ```php
    abstract class Foo {
    use Trait1;
    use Trait1;

    // static members
    // static members

    const _1 = 0;
    const _1 = 0;

    static public $_1;
    static protected $_2;
    static private $_3;
    static public $_1;
    static protected $_2;
    static private $_3;

    static public final function _1() {}
    static public function _2() {}
    static protected final function _3() {}
    static protected function _4() {}
    static private function _5() {}
    static public final function _1() {}
    static public function _2() {}
    static protected final function _3() {}
    static protected function _4() {}
    static private function _5() {}

    // instance members
    // instance members

    public $_4;
    protected $_5;
    private $_6;
    public $_4;
    protected $_5;
    private $_6;

    public function __construct() {}
    public function __construct() {}

    public final function _6() {}
    public function _7() {}
    public abstract function _8();
    public final function _6() {}
    public function _7() {}
    public abstract function _8();

    protected final function _9() {}
    protected function _10() {}
    protected abstract function _11();
    protected final function _9() {}
    protected function _10() {}
    protected abstract function _11();

    private function _12() {}
    private function _12() {}
    }
    ```

  14. jesseschalken revised this gist Oct 8, 2015. 1 changed file with 2 additions and 2 deletions.
    4 changes: 2 additions & 2 deletions code_style.md
    View file
    Original file line number Diff line number Diff line change
    @@ -309,9 +309,9 @@ Class members can be classified along four different dimensions:
    - Type (constant, property, constructor, method)
    - Staticness (static, non-static)
    - Visibility (public, protected, private)
    - Overridability (final, non-final, abstract)
    - Abstrction (final, non-final, abstract)

    All else being equal, class members should be sorted in the order of: staticness, type, visibility, overridability. For example:
    All else being equal, class members should be sorted in the order of: staticness, type, visibility, abstraction. For example:

    ```php
    abstract class Foo {
  15. jesseschalken revised this gist Oct 8, 2015. 1 changed file with 11 additions and 11 deletions.
    22 changes: 11 additions & 11 deletions code_style.md
    View file
    Original file line number Diff line number Diff line change
    @@ -326,10 +326,10 @@ abstract class Foo {
    static private $_3;

    static public final function _1() {}
    static public function _1() {}
    static protected final function _2() {}
    static protected function _2() {}
    static private function _3() {}
    static public function _2() {}
    static protected final function _3() {}
    static protected function _4() {}
    static private function _5() {}

    // instance members

    @@ -339,15 +339,15 @@ abstract class Foo {

    public function __construct() {}

    public final function _4() {}
    public function _5() {}
    public abstract function _6();
    public final function _6() {}
    public function _7() {}
    public abstract function _8();

    protected final function _7() {}
    protected function _8() {}
    protected abstract function _9();
    protected final function _9() {}
    protected function _10() {}
    protected abstract function _11();

    private function _10() {}
    private function _12() {}
    }
    ```

  16. jesseschalken revised this gist Oct 8, 2015. 1 changed file with 2 additions and 0 deletions.
    2 changes: 2 additions & 0 deletions code_style.md
    View file
    Original file line number Diff line number Diff line change
    @@ -325,7 +325,9 @@ abstract class Foo {
    static protected $_2;
    static private $_3;

    static public final function _1() {}
    static public function _1() {}
    static protected final function _2() {}
    static protected function _2() {}
    static private function _3() {}

  17. jesseschalken revised this gist Oct 5, 2015. 1 changed file with 6 additions and 6 deletions.
    12 changes: 6 additions & 6 deletions code_style.md
    View file
    Original file line number Diff line number Diff line change
    @@ -321,13 +321,13 @@ abstract class Foo {

    const _1 = 0;

    public static $_1;
    protected static $_2;
    private static $_3;
    static public $_1;
    static protected $_2;
    static private $_3;

    public static function _1() {}
    protected static function _2() {}
    private static function _3() {}
    static public function _1() {}
    static protected function _2() {}
    static private function _3() {}

    // instance members

  18. jesseschalken revised this gist Oct 5, 2015. 1 changed file with 0 additions and 1 deletion.
    1 change: 0 additions & 1 deletion code_style.md
    View file
    Original file line number Diff line number Diff line change
    @@ -314,7 +314,6 @@ Class members can be classified along four different dimensions:
    All else being equal, class members should be sorted in the order of: staticness, type, visibility, overridability. For example:

    ```php
    <?php
    abstract class Foo {
    use Trait1;

  19. jesseschalken revised this gist Oct 5, 2015. 1 changed file with 16 additions and 12 deletions.
    28 changes: 16 additions & 12 deletions code_style.md
    View file
    Original file line number Diff line number Diff line change
    @@ -305,30 +305,32 @@ From Steve McConnell's Code Complete Second Edition chapter on Layout and Style:
    ## Class member ordering

    Class members can be sorted along four different dimensions:
    - Member type (constant, property, constructor, method)
    Class members can be classified along four different dimensions:
    - Type (constant, property, constructor, method)
    - Staticness (static, non-static)
    - Visibility (public, protected, private)
    - Overridability (final, non-final, abstract)

    Class members should typically be sorted along those dimensions in the order of: staticness, type, visibility, overridability.

    Example:
    All else being equal, class members should be sorted in the order of: staticness, type, visibility, overridability. For example:

    ```php
    <?php
    abstract class Foo {
    use Trait1;

    // static members

    const _1 = 0;

    static public $_1;
    static protected $_2;
    static private $_3;
    public static $_1;
    protected static $_2;
    private static $_3;

    public static function _1() {}
    protected static function _2() {}
    private static function _3() {}

    static public function _1() {}
    static protected function _2() {}
    static private function _3() {}
    // instance members

    public $_4;
    protected $_5;
    @@ -346,4 +348,6 @@ abstract class Foo {

    private function _10() {}
    }
    ```
    ```

    It is permissable to use a different ordering if the circumstances favour it. For example, a very large class may be more easily navigated with members arranged by topic.
  20. jesseschalken revised this gist Oct 5, 2015. 1 changed file with 3 additions and 3 deletions.
    6 changes: 3 additions & 3 deletions code_style.md
    View file
    Original file line number Diff line number Diff line change
    @@ -317,9 +317,10 @@ Example:

    ```php
    <?php

    abstract class Foo {
    const FOO = 0;
    use Trait1;

    const _1 = 0;

    static public $_1;
    static protected $_2;
    @@ -345,5 +346,4 @@ abstract class Foo {

    private function _10() {}
    }

    ```
  21. jesseschalken revised this gist Oct 5, 2015. 1 changed file with 46 additions and 1 deletion.
    47 changes: 46 additions & 1 deletion code_style.md
    View file
    Original file line number Diff line number Diff line change
    @@ -301,4 +301,49 @@ For this purpose, 2 or 4 is reasonable and common. I find 4 spaces to be a nice

    From Steve McConnell's Code Complete Second Edition chapter on Layout and Style:

    > Subjects scored 20 to 30 percent higher on a test of comprehension when programs had a two-to-four-spaces indentation scheme than they did when programs had no indentation at all.The same study found that it was important to neither under-emphasize nor over emphasize a program’s logical structure. The lowest comprehension scores were achieved on programs that were not indented at all. The second lowest were achieved on programs that used six-space indentation. The study concluded that two-to-four-space indentation was optimal. Interestingly, many subjects in the experiment felt that the six-space indentation was easier to use than the smaller indentations, even though their scores were lower. That’s probably because six space indentation looks pleasing. But regardless of how pretty it looks, six-space indentation turns out to be less readable. This is an example of a collision be tween aesthetic appeal and readability.
    > Subjects scored 20 to 30 percent higher on a test of comprehension when programs had a two-to-four-spaces indentation scheme than they did when programs had no indentation at all.The same study found that it was important to neither under-emphasize nor over emphasize a program’s logical structure. The lowest comprehension scores were achieved on programs that were not indented at all. The second lowest were achieved on programs that used six-space indentation. The study concluded that two-to-four-space indentation was optimal. Interestingly, many subjects in the experiment felt that the six-space indentation was easier to use than the smaller indentations, even though their scores were lower. That’s probably because six space indentation looks pleasing. But regardless of how pretty it looks, six-space indentation turns out to be less readable. This is an example of a collision be tween aesthetic appeal and readability.
    ## Class member ordering

    Class members can be sorted along four different dimensions:
    - Member type (constant, property, constructor, method)
    - Staticness (static, non-static)
    - Visibility (public, protected, private)
    - Overridability (final, non-final, abstract)

    Class members should typically be sorted along those dimensions in the order of: staticness, type, visibility, overridability.

    Example:

    ```php
    <?php

    abstract class Foo {
    const FOO = 0;

    static public $_1;
    static protected $_2;
    static private $_3;

    static public function _1() {}
    static protected function _2() {}
    static private function _3() {}

    public $_4;
    protected $_5;
    private $_6;

    public function __construct() {}

    public final function _4() {}
    public function _5() {}
    public abstract function _6();

    protected final function _7() {}
    protected function _8() {}
    protected abstract function _9();

    private function _10() {}
    }

    ```
  22. jesseschalken revised this gist Oct 1, 2015. 1 changed file with 4 additions and 0 deletions.
    4 changes: 4 additions & 0 deletions code_style.md
    View file
    Original file line number Diff line number Diff line change
    @@ -298,3 +298,7 @@ So what should the tab size be? The size is a balance between:
    - Keeping the first indented line close enough to the line that introduced it so as not to disrupt the flow of reading.

    For this purpose, 2 or 4 is reasonable and common. I find 4 spaces to be a nice balance. 8 seems to throw your code to the other side of the screen. 2 seems to reduce the indentation silhouette to nothing more than a wobbly line.

    From Steve McConnell's Code Complete Second Edition chapter on Layout and Style:

    > Subjects scored 20 to 30 percent higher on a test of comprehension when programs had a two-to-four-spaces indentation scheme than they did when programs had no indentation at all.The same study found that it was important to neither under-emphasize nor over emphasize a program’s logical structure. The lowest comprehension scores were achieved on programs that were not indented at all. The second lowest were achieved on programs that used six-space indentation. The study concluded that two-to-four-space indentation was optimal. Interestingly, many subjects in the experiment felt that the six-space indentation was easier to use than the smaller indentations, even though their scores were lower. That’s probably because six space indentation looks pleasing. But regardless of how pretty it looks, six-space indentation turns out to be less readable. This is an example of a collision be tween aesthetic appeal and readability.
  23. jesseschalken revised this gist Oct 1, 2015. 1 changed file with 1 addition and 1 deletion.
    2 changes: 1 addition & 1 deletion code_style.md
    View file
    Original file line number Diff line number Diff line change
    @@ -270,7 +270,7 @@ Chromium (Google)|K&R|spaces|2|no|[code](https://chromium.googlesource.com/chrom
    LibreOffice|Allman|spaces|4|no|[code](http://cgit.freedesktop.org/libreoffice/core/tree/formula/source/ui/dlg/formula.cxx)
    PHP|K&R|tabs|8|no|[code](https://github.com/php/php-src/blob/master/Zend/zend_string.c), [code 2](https://github.com/php/php-src/blob/master/Zend/zend_operators.c)
    Vim|Allman|mixed|4|no|[code](https://github.com/vim/vim/blob/master/src/edit.c), [code 2](https://github.com/vim/vim/blob/master/src/gui.c)
    Git|K&R|tabs|8|no|[code](https://github.com/git/git/blob/master/send-pack.c)
    Git|K&R|tabs|8|no|[CodingGuidelines](https://github.com/git/git/blob/master/Documentation/CodingGuidelines), [code](https://github.com/git/git/blob/master/send-pack.c)

    Why does what other projects do matter? Only for familiarity. Switching between code written in different styles can be jarring. With most code having been written in K&R, the code you write will feel more familiar to others and others' code will feel more familiar to you by sharing the style.

  24. jesseschalken revised this gist Oct 1, 2015. 1 changed file with 1 addition and 1 deletion.
    2 changes: 1 addition & 1 deletion code_style.md
    View file
    Original file line number Diff line number Diff line change
    @@ -270,7 +270,7 @@ Chromium (Google)|K&R|spaces|2|no|[code](https://chromium.googlesource.com/chrom
    LibreOffice|Allman|spaces|4|no|[code](http://cgit.freedesktop.org/libreoffice/core/tree/formula/source/ui/dlg/formula.cxx)
    PHP|K&R|tabs|8|no|[code](https://github.com/php/php-src/blob/master/Zend/zend_string.c), [code 2](https://github.com/php/php-src/blob/master/Zend/zend_operators.c)
    Vim|Allman|mixed|4|no|[code](https://github.com/vim/vim/blob/master/src/edit.c), [code 2](https://github.com/vim/vim/blob/master/src/gui.c)
    Git|K&R|tabs|n/a|no|[code](https://github.com/git/git/blob/master/send-pack.c)
    Git|K&R|tabs|8|no|[code](https://github.com/git/git/blob/master/send-pack.c)

    Why does what other projects do matter? Only for familiarity. Switching between code written in different styles can be jarring. With most code having been written in K&R, the code you write will feel more familiar to others and others' code will feel more familiar to you by sharing the style.

  25. jesseschalken revised this gist Oct 1, 2015. 1 changed file with 1 addition and 0 deletions.
    1 change: 1 addition & 0 deletions code_style.md
    View file
    Original file line number Diff line number Diff line change
    @@ -270,6 +270,7 @@ Chromium (Google)|K&R|spaces|2|no|[code](https://chromium.googlesource.com/chrom
    LibreOffice|Allman|spaces|4|no|[code](http://cgit.freedesktop.org/libreoffice/core/tree/formula/source/ui/dlg/formula.cxx)
    PHP|K&R|tabs|8|no|[code](https://github.com/php/php-src/blob/master/Zend/zend_string.c), [code 2](https://github.com/php/php-src/blob/master/Zend/zend_operators.c)
    Vim|Allman|mixed|4|no|[code](https://github.com/vim/vim/blob/master/src/edit.c), [code 2](https://github.com/vim/vim/blob/master/src/gui.c)
    Git|K&R|tabs|n/a|no|[code](https://github.com/git/git/blob/master/send-pack.c)

    Why does what other projects do matter? Only for familiarity. Switching between code written in different styles can be jarring. With most code having been written in K&R, the code you write will feel more familiar to others and others' code will feel more familiar to you by sharing the style.

  26. jesseschalken revised this gist Oct 1, 2015. 1 changed file with 1 addition and 1 deletion.
    2 changes: 1 addition & 1 deletion code_style.md
    View file
    Original file line number Diff line number Diff line change
    @@ -280,7 +280,7 @@ Why does what other projects do matter? Only for familiarity. Switching between

    The requirement of #2, that all software displaying the code be configured to have the correct tab size, is at best inconvenient, at worst impossible. The problem is there is a large and diverse range of software that will be involved in displaying your code, including:
    - Debuggers (`gdb`, `lldb`, `hphpd`, Firefox/Chrome JavaScript debugger...)
    - Error reporting systems (Bugsnag, Rollbar...)
    - Error reporting systems (Bugsnag, Rollbar, FailWhale, Whoops!...)
    - Source code browsers (GitHub, Bitbucket, Upsource...)
    - Code review tools (GitHub, Bitbucket, Upsource, Crucible...)
    - Diff tools (`git diff`, GitHub app, Meld, TortoiseGit, KDiff...)
  27. jesseschalken revised this gist Sep 30, 2015. 1 changed file with 1 addition and 1 deletion.
    2 changes: 1 addition & 1 deletion code_style.md
    View file
    Original file line number Diff line number Diff line change
    @@ -278,7 +278,7 @@ Why does what other projects do matter? Only for familiarity. Switching between
    1. The good thing about tabs is that each person _can_ configure their tools to render tabs using their preferred size.
    2. The bad thing about tabs is that each person _must_ configure their tools to render tabs using their preferred size.

    _2._ is at best inconvenient, at worst impossible. The problem is there is a large and diverse range of software that will be involved in displaying your code, including:
    The requirement of #2, that all software displaying the code be configured to have the correct tab size, is at best inconvenient, at worst impossible. The problem is there is a large and diverse range of software that will be involved in displaying your code, including:
    - Debuggers (`gdb`, `lldb`, `hphpd`, Firefox/Chrome JavaScript debugger...)
    - Error reporting systems (Bugsnag, Rollbar...)
    - Source code browsers (GitHub, Bitbucket, Upsource...)
  28. jesseschalken revised this gist Sep 30, 2015. 1 changed file with 1 addition and 1 deletion.
    2 changes: 1 addition & 1 deletion code_style.md
    View file
    Original file line number Diff line number Diff line change
    @@ -278,7 +278,7 @@ Why does what other projects do matter? Only for familiarity. Switching between
    1. The good thing about tabs is that each person _can_ configure their tools to render tabs using their preferred size.
    2. The bad thing about tabs is that each person _must_ configure their tools to render tabs using their preferred size.

    #2 is at best inconvenient, at worst impossible. The problem is there is a large and diverse range of software that will be involved in displaying your code, including:
    _2._ is at best inconvenient, at worst impossible. The problem is there is a large and diverse range of software that will be involved in displaying your code, including:
    - Debuggers (`gdb`, `lldb`, `hphpd`, Firefox/Chrome JavaScript debugger...)
    - Error reporting systems (Bugsnag, Rollbar...)
    - Source code browsers (GitHub, Bitbucket, Upsource...)
  29. jesseschalken revised this gist Sep 30, 2015. 1 changed file with 11 additions and 9 deletions.
    20 changes: 11 additions & 9 deletions code_style.md
    View file
    Original file line number Diff line number Diff line change
    @@ -275,23 +275,25 @@ Why does what other projects do matter? Only for familiarity. Switching between

    ## Why 4 spaces?

    - The good thing about tabs is that each person _can_ configure their tools to render tabs using their preferred size.
    - The bad thing about tabs is that each person _must_ configure their tools to render tabs using their preferred size.
    1. The good thing about tabs is that each person _can_ configure their tools to render tabs using their preferred size.
    2. The bad thing about tabs is that each person _must_ configure their tools to render tabs using their preferred size.

    The problem is there is a large list of software that is typically used to view code, including:
    #2 is at best inconvenient, at worst impossible. The problem is there is a large and diverse range of software that will be involved in displaying your code, including:
    - Debuggers (`gdb`, `lldb`, `hphpd`, Firefox/Chrome JavaScript debugger...)
    - Error reporting systems (Bugsnag, Rollbar...)
    - Source code browsers (GitHub, Bitbucket, Upsource...)
    - Code review tools (GitHub, Bitbucket, Upsource, Crucible...)
    - Diff tools (`git diff`, GitHub app, Meld, TortoiseGit, KDiff...)
    - Editors (...)
    - Editors (including both IDEs and simple text editors (Vim, Gedit...) used to quicktly view files and make small changes)

    Each tool will have it's own default display size for a tab (usually 8) and each tool may or may not let you change it. GitHub, for example, renders tabs with 8 spaces, which can only temporarily be changed by adding `?ts=...` to the URL and reloading the page.
    Not to mention code samples that are put in emails, chat messages, code review/bug tracker issues/comments, blog posts and presentation slides.

    Additionally, putting sample code in an email, a blog post, a bug tracker issue/comment, or presentation slide will rarely give you the indent size.
    Each tool will have it's own default display size for a tab (usually 8) and each tool may or may not let you change it. GitHub, for example, renders tabs with 8 spaces, which can only temporarily be changed by adding `?ts=...` to the URL and reloading the page. Consequently, using tabs, you are destined to find yourself reading your code with the wrong indent size (usually 8), whether you like it or not, and depending on the tool, you may not be able to do anything about it. It is not possible to impose the requirement of user-configurable tab sizes on all the software which happens to render your code.

    Consequently, using tabs, you are bound end up reading your code with the wrong indent size (usually 8), whether you like it or not, and you may not be able to do anything about it.
    Spaces impose no such requirement. By embedding the correct tab size directly in the code, the code is rendered correctly everywhere, even if you cut and paste it into an email.

    Using spaces alleviates this concern. No requirement is imposed on the software that happens to be displaying the code. The correct indent size is instead embedded in the source code itself, so that it is rendered correctly no matter how or where it happens to be viewed.
    So what should the tab size be? The size is a balance between:
    - Giving the indent a big enough "kick" so that the structure of the code pops out.
    - Keeping the first indented line close enough to the line that introduced it so as not to disrupt the flow of reading.

    The indent size of 4 is a matter of taste. 2 makes indents a little too soft for my liking. It makes the indent silhouette nothing more than a slightly wobbly line. 4 gives the indents a bit of kick without throwing your code to the other side of the screen like 8 does.
    For this purpose, 2 or 4 is reasonable and common. I find 4 spaces to be a nice balance. 8 seems to throw your code to the other side of the screen. 2 seems to reduce the indentation silhouette to nothing more than a wobbly line.
  30. jesseschalken revised this gist Sep 30, 2015. 1 changed file with 1 addition and 1 deletion.
    2 changes: 1 addition & 1 deletion code_style.md
    View file
    Original file line number Diff line number Diff line change
    @@ -286,7 +286,7 @@ The problem is there is a large list of software that is typically used to view
    - Diff tools (`git diff`, GitHub app, Meld, TortoiseGit, KDiff...)
    - Editors (...)

    Each tool will have it's own default display size for a tab (usually 8) and each tool may or may not let you change it. GitHub, for example, renders tabs with 8 spaces, which can only temporarily be changed by adding `?ts...` to the URL and reloading the page.
    Each tool will have it's own default display size for a tab (usually 8) and each tool may or may not let you change it. GitHub, for example, renders tabs with 8 spaces, which can only temporarily be changed by adding `?ts=...` to the URL and reloading the page.

    Additionally, putting sample code in an email, a blog post, a bug tracker issue/comment, or presentation slide will rarely give you the indent size.