Off-side rule

A computer programming language is said to adhere to the off-side rule of syntax if blocks in that language are expressed by their indentation. The term was coined by Peter Landin, possibly as a pun on the offside rule in association football. This is contrasted with free-form languages, notably curly-bracket programming languages, where indentation has no computational meaning and indent style is only a matter of coding conventions and formatting. Off-side-rule languages are also described as having significant indentation.
Definition.
Peter Landin, in his 1966 article "The Next 700 Programming Languages", defined the off-side rule thus: "Any non-whitespace token to the left of the first such token on the previous line is taken to be the start of a new declaration."
Code examples.
The following is an example of indentation blocks in Python. The colons are part of the Python language syntax for readability; they are not needed to implement the off-side rule.
In Python, the rule is taken to define the boundaries of statements rather than declarations.
def is_even(a: int) -&gt; bool:
 """Determine whether number 'a' is even."""
 if a % 2 == 0:
 print('Even!')
 return True
 print('Odd!')
 return False
Python also suspends the off-side rule within brackets. A statement within brackets continues until its brackets match (or mismatch):
 "this": True,
 "that": False,
 "them": [1, 2,
3, 4, 5, 
6, 7, 8,
9, 10, 11, 12]
In this dictionary, the keys are indented, and a list is split between four lines.
Implementation.
The off-side rule can be implemented in the lexical analysis phase, as in Python, where increasing the indenting results in the lexer outputting an codice_1 token, and decreasing the indenting results in the lexer outputting a codice_2 token. These tokens correspond to the opening brace codice_3 and closing brace codice_4 in languages that use braces for blocks, and means that the phrase grammar does not depend on whether braces or indentation are used. This requires that the lexer hold state, namely the current indent level, and thus can detect changes in indentation when this changes, and thus the lexical grammar is not context-free: codice_1 and codice_2 depend on the contextual information of the prior indent level.
Alternatives.
The primary alternative to delimiting blocks by indenting, popularized by broad use and influence of the language C, is to ignore whitespace characters and mark blocks explicitly with curly brackets (i.e., codice_3 and codice_4) or some other delimiter. While this allows for more formatting freedom – a developer might choose not to indent small pieces of code like the break and continue statements – sloppily indented code might lead the reader astray, such as the goto fail bug.
Lisp and other S-expression-based languages do not differentiate statements from expressions, and parentheses are enough to control the scoping of all statements within the language. As in curly bracket languages, whitespace is mostly ignored by the reader (i.e., the read function). Whitespace is used to separate tokens. The explicit structure of Lisp code allows automatic indenting, to form a visual cue for human readers.
Another alternative is for each block to begin and end with explicit keywords. For example, in ALGOL 60 and its descendant Pascal, blocks start with keyword codice_9 and end with keyword codice_10. In some languages (but not Pascal), this means that newlines "are" important (unlike in curly brace languages), but the indentation is not. In BASIC and Fortran, blocks begin with the block name (such as codice_11) and end with the block name prepended with codice_12 (e.g., codice_13). In Fortran, each and every block can also have its own unique block name, which adds another level of explicitness to lengthy code. ALGOL 68 and the Bourne shell (sh, and bash) are similar, but the end of the block is usually given by the name of the block written backward (e.g., codice_14 starts a switch statement and it spans until the matching codice_15; similarly conditionals codice_16...codice_17...[codice_18...[codice_19...]]codice_20 or "for" loops codice_21...codice_22...codice_23 in ALGOL68 or codice_21...codice_22...codice_26 in bash).
An interesting variant of this occurs in Modula-2, a Pascal-like language which does away with the difference between one and multiline blocks. This allows the block opener (codice_3 or codice_28) to be skipped for all but the function level block, requiring only a block terminating token (codice_4 or codice_12). It also fixes dangling else. Custom is for the codice_10 token to be placed on the same indent level as the rest of the block, giving a blockstructure that is very readable.
One advantage to the Fortran approach is that it improves readability of long, nested, or otherwise complex code. A group of outdents or closing brackets alone provides no contextual cues as to which blocks are being closed, necessitating backtracking, and closer scrutiny while debugging. Further, languages that allow a suffix for END-like keywords further improve such cues, such as codice_32 versus codice_33. However, modern source code editors often provide visual indicators, such as syntax highlighting, and features such as code folding to assist with these drawbacks.
Productivity.
In the language Scala, early versions allowed curly braces only. Scala 3 added an option to use indenting to structure blocks. Designer Martin Odersky said that this improves productivity overall by 10%, turns out to be the most productive change introduced in Scala 3, and advises its use.