Why Do Programmers Indent Their Code

[Karlyn Hemmerling]

Thisis a bit of a "holy war" among software developers; one that's been the subject of many debates and in-jokes. I use spaces, but I never thought it was particularly important. But today we're releasing the raw data behind the Stack Overflow 2017 Developer Survey, and some analysis suggests this choice matters more than I expected.

Analyzing the data leads us to an interesting conclusion. Coders who use spaces for indentation make more money than ones who use tabs, even if they have the same amount of experience:

Indeed, the median developer who uses spaces had a salary of $59,140, while the median tabs developer had a salary of $43,750. (Note that all the results were converted into US dollars from each respondent's currency). Developers who responded "Both" were generally indistinguishable from ones who answered "Tabs": I'll leave them out of many of the remaining analyses.

This is an amusing result, but of course it's not conclusive by itself. When I first discovered this effect, I assumed that it was confounded by a factor such as country or programming language. For example, it's conceivable that developers in low GDP-per-capita countries could be more likely to use tabs, and therefore such developers tend to have lower salaries on average.

As another hypothesis, we know that different types of developers often use different indentation (e.g. with DevOps developers more likely to use spaces and mobile developers more likely to use tabs), often because they use different editors and languages. The Developer Survey asked both about what programming languages each respondent uses (Python, Javascript, etc) and what "type" of developer they are (web developer, embedded developer, etc).

Yes, the effect existed within every subgroup of developers. (This gave a similar result even when filtering for developers only in a specific country, or for ones with a specific range of experience). Note that respondents could select multiple languages, so each of these groups are overlapping to some degree.

I did several other visual examinations of possible confounding factors (such as level of education or company size), and found basically the same results: spaces beat tabs within every group. Now that the raw data is available, I encourage other statisticians to check other confounders themselves.

The model estimated that using spaces instead of tabs is associated with an 8.6% higher salary (confidence interval (6%, 10.4%), p-value % change each factor contributed to a salary rather than the dollar amount). Put another way, using spaces instead of tabs is associated with as high a salary difference as an extra 2.4 years of experience.

So... this is certainly a surprising result, one that I didn't expect to find when I started exploring the data. And it is impressively robust even when controlling for many confounding factors. As an exercise I tried controlling for many other confounding factors within the survey data beyond those mentioned here, but it was difficult to make the effect shrink and basically impossible to make it disappear.

Correlation is not causation, and we can never be sure that we've controlled for all the confounding factors present in a dataset, or indeed that the confounders were measured in the survey at all. If you're a data scientist, statistician, or analyst, I encourage you to download the raw survey data and examine it for yourself. You can find the code behind this blog post here if you'd like to reproduce the analysis. In any case we'd be interested in hearing hypotheses about this relationship.

Indentation is a fundamental aspect of code styling, and plays a large role in influencing readability. First of all, indented code is easier to read through than unindented code. Compare the following:

With unindented code, the overall structure of the code might be somewhat difficult to see. However, with indented code, the overall structure of the code jumps out at you. Tabs tell you that a line of code is inside a function, loop, if statement, or else statement. Knowing which parts of the code is inside what will become especially important in the non-Karel Javascript sections.

Because the code on line 3 is indented, it may seem to be part of the body of the while loop. But, remember that without brackets, the while loop body can only consist of one line of code. So, this code is really equivalent to:

How should this be indented? Well, let's remember our general rule... code between curly brackets should be indented. See the curly brackets in the example() function? Now we look at everything in between those curly brackets, and we indent all the code there one time by pressing the tab key. So the correctly indented version would be this:

So how about if inside of a set of brackets is another set of brackets? Well, if there is a set of brackets inside another set of brackets, you will indent one time for each set of brackets your code is in between.

Notice how there is a set of curly brackets for the karelImpressesVegeta() function and a set of curly brackets for the for loop that is inside. To indent this code properly, we can think of this in two steps:

Technically, it is fine to either indent using the tab key or with the space bar. Indenting once with the tab key means just pressing the tab key once. Indenting once with the space bar means pressing the space bar 4 times.

Even though you can indent using tab or space, indenting using the tab key is recommended, because there are higher chances of making mistakes in indenting if you use the space bar (like if you press the space bar 3 times instead of 4).

In computer programming, indentation style is a convention, a.k.a. style, governing the indentation of blocks of source code. An indentation style generally involves consistent width of whitespace (indentation size) before each line of a block, so that the lines of code appear to be related, and dictates whether to use space or tab characters for the indentation whitespace.

This article primarily addresses styles for free-form programming languages. As the name implies, such language code need not follow an indentation style. Indentation is a secondary notation that is often intended to lower cognitive load for a programmer to understand the structure of the code. Indentation can clarify the separation between the code executed based on control flow.

Structured languages, such as Python and occam, use indentation to determine the structure instead of using braces or keywords; this is termed the off-side rule. In such languages, indentation is meaningful to the language processor (such as compiler or interpreter). A programmer must conform to the language's indentation rules although may be free to choose indentation size.

This article focuses on curly-bracket languages (that delimit blocks with curly brackets, a.k.a. curly braces, a.k.a. braces) and in particular C-family languages, but a convention used for one language can be adapted to another language. For example, a language that uses BEGIN and END keywords instead of braces can be adapted by treating BEGIN the same as the open brace and so on.

Despite the ubiquitous use of indentation styles, little research has been conducted on its value. First experiments, conducted by Weissman in 1974, did not show any effect.[1]In 2023, an experiment by Morzeck et al.[2] showed significant positive effect for nested if statements where non-indented code required on average 179% more time to read than indented code.

In this style, a function has its opening and closing braces on their own lines and with the same indentation as the declaration, and with statements indented an additional level than the declaration. 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 else or while.

The One True Brace Style [6] (abbreviated 1TBS or OTBS[7]) 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.[8]

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 goto fail bug.

Cited advantages include shorter code (than K&R) since the starting brace needs no extra line, and the ending brace lines up with the statement it conceptually belongs to. One cost of this style is that the ending brace adds a line, which can be partly resolved in if/else blocks and do/while blocks.

A significant body of 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[12][13][14] used this K&R variant, and as a result, most of the standard source code for the Java API is written in this style. It is also a popular indentation style for ActionScript and JavaScript, along with the Allman style.

Stroustrup does not indent the labels public: and 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.[16]

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 code. It is essentially a thoroughly documented variant of K&R style as used in the Bell Labs Version 6 & 7 Unix source code.[17]

3a8082e126