I am learning Haskell, and I was looking for an auto indentation tool. I didn't look much, and learned that in Haskell (as in Python), indentation signifies a block. As a result, I'm guessing that it's impossible to create an auto formatting tool, as strong as in other languages in the C family, that use explicit markers, such as { } (curly braces) or begin end keywords.

I do not mind a language enforcing indentation for readability, but I cannot understand the benefits over both enforcing indentation and having some explicit marker, so that automated tools, can understand what belongs in which block.

If the preference of indentation marking a block, is so that code looks better, then I still don't understand the advantage. Given that tabs and spaces are represented differently in different editors and different fonts (mono-space fonts for example look tidier), it's infeasible to expect the programmer to present the code decently. A tool that can take into account the current text editor, would be much more appropriate to format the code correctly.

Why would a language designer choose indentation over explicit block markers?

  • 9
    Not an answer, but Haskell makes whitespace sensitivity a lot more optional than python. You can use semicolons for most things, and wrap blocks in curly braces if desired. let x =1; y = 2; z = 3 is completely valid, as is do { putStrLn $ show x; putStrLn $ show y; putStrLn $ show z; }. Those don't need to be on the same line.
    – KChaloux
    Mar 17, 2016 at 13:17
  • 11
    "it's impossible to create an auto formatting tool" - actually, there is no need for such an auto formatting tool in Python because of the indentation rules.
    – Doc Brown
    Mar 17, 2016 at 14:15
  • 17
    Um, increasing indentation is an explicit block marker. Mar 17, 2016 at 14:22
  • 4
    @K.Gkinis: The best source for the exact motivations behind a language design decision are the language designers themselves. Mar 17, 2016 at 14:56
  • 3
    This question is not actually subjective. It asks why some language designers chose a certain syntax. This can be answered. If the question had asked which syntax is best, it would be subjective.
    – JacquesB
    Mar 17, 2016 at 15:11

3 Answers 3


Guido Von Rossum

From an interview with Guido Van Rossum, which can be seen in fulltext with books.google.com (emphasis mine):

The choice of indentation for grouping was not a novel concept in Python; I inherited this from ABC, but it also occurred in occam, an older language. I don't know if the ABC authors got the idea from occam, or invented it independently, or if there was a common ancestor. Of course, I could have chose not to follow ABC’s lead, as I did in other areas (e.g., ABC used uppercase for language keywords and procedure names, an idea I did not copy), but I had come to like the feature quite a bit while using ABC, as it seemed to do away with a certain type of pointless debate common amongst C users at the time, about where to place the curly braces.

Von Rossum was heavily inspired from ABC, and even though he did not have to copy all of it, the use of indentation was kept because it could be beneficial in avoiding religious wars.

I also was well aware that readable code uses indentation voluntarily anyway to indicate grouping, and I had come across subtle bugs in code where the indentation disagreed with the syntactic grouping using curly braces—the programmer and any reviewers had assumed that the indentation matched the grouping and therefore not noticed the bug. Again, a long debugging session taught a valuable lesson.

Rossum also witnessed bugs due to inconsistency between grouping and indent, and apparently though that relying on indentation only to structure the code would be safer from programming errors1.

Donald E. Knuth & Peter J. Landin

In the referenced interview, Guido mentions Don Knuth's idea of using indentation. This is detailed in The Knuth Indentation Quote rediscovered, which quotes Structured Programming with goto Statements. Knuth also references Peter John Landin's The next 700 programming languages (see the Discussion section about indentation). Landin designed ISWIM which looks like the first language with indentation instead of begin/end blocks. Those papers are more about the feasibility of using indentation for structuring programs rather that actual arguments in favor of doing so.

1. I think that this is in fact an argument in favor of having both grouping constructs and auto-formatting, in order to catch and recover from programming errors, which are bound to happen. If you screw up your indentation in Python, the person who debugs your code will have to guess which is correct:

if (test(x)):

Shall bar always be called or only if the test succeed?

Grouping constructs add a level of redundancy that help you spot a mistake when you auto-indent your code. In C, the equivalent code can be auto-indented as follows:

if (test(x))

If I intended for bar to be at the same level as foo, then auto-indenting based on the code structure let me see that there is something wrong that can be fixed by adding braces around foo and bar.

In Python: Myths about Indentation, there is a supposedly bad example from C:

/*  Warning:  bogus C code!  */

if (some condition)
        if (another condition)

That's the same case as above, in Emacs, I highlight the whole block/function, press Tab, and then all the code is reindented. The discrepancy between human indentation and code structure tells me something is off (that and the preceding comment!).

Besides, the intermediate code where indentation is off in C simply does not make it through the master branch, all the style checks in place would make GCC/Jenkins scream at me. I recently had a problem similar to the one described above in Python, with a statement off by one level of indentation. Sometimes I have code in C that goes beyond a closing brace, but then I hit Tab and the code indents "wrongly": that's one more chance to see the bug.

  • 4
    "To avoid religious wars..." I'm surprised that the true reason is so trivial. Mar 17, 2016 at 15:04
  • 3
    @RobertHarvey: The emphasis on that phrase is by coredump, not by van Rossum. It is not the primary reason if you read the van Rossum quote in context.
    – JacquesB
    Mar 17, 2016 at 16:13
  • 2
    @coredump: Your choice of bolding (which is not in the original source) make it seem like the primary reason is to avoid debate about where to place the brace. But if you read the quote in the original context (without misleading bolding) it is pretty clear that this is only an afterthought, and the primary reason is readability and avoiding bugs due to misleading indentation.
    – JacquesB
    Mar 17, 2016 at 16:36
  • 9
    I don't get you personal comment though: If you screw up indentation in Python, then you have a bug. If you screw up braces in C you have a bug. If you use auto-indenting it is exactly the same in both languages. And if you don't use auto-indenting, the bug can be sneakily hidden in C in a way that is not possible in Python.
    – JacquesB
    Mar 17, 2016 at 17:47
  • 3
    @JacquesB because typing a closing brace is something that you actively do; not indenting enough is something you can forget to do. Of course you can forget to close a brace at the right time, but you'll have to do it eventually and get another chance to think about it. I guess python works good for beginners because it forces attention onto indentation.
    – marstato
    Apr 30, 2019 at 14:38

This is highly subjective and the cause for many a flame war. However:

Having symbols delimiting blocks and indentation violates the DRY principle, since you express the same information in two different ways. The existence of automated indentation tools is a symptom of this DRY violation: That you can automatically generate the indentation shows that it is redundant information, and it means the indentation and symbols may get out of sync which lead to misleading code.

The Python Design and History FAQ states this very clearly:

Why does Python use indentation for grouping of statements?

Guido van Rossum believes that using indentation for grouping is extremely elegant and contributes a lot to the clarity of the average Python program. Most people learn to love this feature after a while.

Since there are no begin/end brackets there cannot be a disagreement between grouping perceived by the parser and the human reader.

It is true that you cannot create an auto indentation tool for Python, but this is a good thing: It means you don't have redundancies in the syntax which you need automated tools to reconcile.

The tabs vs spaces is a legitimate concern in Python, and it is recommended to never mix tabs and spaces (for indentation) in the same codebase.

Python inherited the significant indentation from the (now obsolete) predecessor language ABC. ABC is one of the very few programming languages which have used usability testing to direct the design. So while discussions about syntax usually comes down to subjective opinions and personal preferences, the choice of significant indentation actually have a sounder foundation.

  • 10
    Double-entry accounting violates DRY too. Redundancy is sometimes a feature.
    – coredump
    Mar 17, 2016 at 15:53
  • 4
    @coredump: True, but it is a deliberately designed redundancy. Most programming languages, including Python, contain deliberately chosen redundancies - e.g. the pass keyword which could be inferred automatically, but requiring it to be explicit helps discover mistakes. The accidental redundancy of having both begin/end symbols (for the compiler) and indentation (for the human reader) seem to cause more mistakes than it catches. At least this seems to be the view of van Rossum.
    – JacquesB
    Mar 17, 2016 at 16:18
  • 4
    @coredump You miss COBOL's PROCEDURE DIVISION. too? I never can tell where where the DATA DIVISION ends and the procedures start in these newfangled languages.
    – msw
    Mar 18, 2016 at 7:24
  • 3
    @coredump: "seeing indentation contradicts what I had in mind is sufficient to prevent errors" - exactly.
    – JacquesB
    Mar 18, 2016 at 10:25
  • 1
    @MaxBinnewies: Automatic indentation tools do violate dry, since they modify the source code, so two representations of the same information have to be maintained. If the indentation was purely presentational in the IDE and no whitespace was actually inserted in the file, then it would not violate DRY, but no mainstream IDE works like that as far as I know.
    – JacquesB
    Jul 11, 2018 at 7:48

Language designers choose syntactically significant whitespace because they believe (or at least think their potential users believe) that the semi-colons and braces add noise when reading code, harming productivity. Another common reason is that bad/inconsistent coding style harms readability - by forcing a common indentation scheme, the language has better readability over-all. That later reason is less important now that auto-formatting IDEs are more common, but can still apply.

  • 1
    I can see why one would consider semicolons and curly braces noise. But isn't it less productive to have to type 4 / 8 / 12 times space? And if you miss one (since they're invisible) you're in trouble.
    – RaidenF
    Mar 17, 2016 at 14:50
  • 7
    That's why you use tabs instead of spaces, or an IDE that understands how to convert tabs into four-space blocks. Mar 17, 2016 at 14:58
  • 1
    @K.Gkinis: Indents are not invisible. Only whitespace at the ends of lines is invisible, but this is not significant in any language. Only if you mix tabs and spaces will you get into trouble. So don't do that.
    – JacquesB
    Mar 18, 2016 at 7:43
  • 1
    @JacquesB: the problem with visibility/invisibility of indentation is that as a human you often can't tell the difference between spaces and a tab, whereas the computer can and often does. So, while the indentation is visible, the way the computer interprets the indentation can be different. That's the real problem: when the computer treats the invisible characters differently than humans. Humans measure indentation as distance on a screen, computers may measure it as literal number of characters. that's the invisible part. Mar 31, 2016 at 12:29
  • 2
    @BryanOakley: Yeah, this is why you shouldn't mix tabs and spaces in indentation.
    – JacquesB
    Mar 31, 2016 at 12:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.