<p>In my programming language, <a href="https://flatassembler.github.io/AEC_specification" rel="noreferrer">AEC</a>, I am using keywords <code>EndIf</code> and <code>EndWhile</code> with the same meaning as in SmallBasic, and I am also using <code>EndFunction</code> (corresponding to <code>EndSub</code> in SmallBasic) and <code>EndStructure</code> (for ending the structures). But I have noticed very few languages use different tokens for those things. Of the programming languages I know, only SmallBasic, Ada and VHDL (with a syntax based on Ada) distinguish those things. Most programming languages I know use <code>}</code> for all of those things, and those that do not (such as Pascal or MatLab or Lua) use <code>end</code> for all of those. Why?</p>
<p>An obvious answer is that using the same token for all those things makes the programming language slightly easier to parse. But I think that cannot be the main reason. Furthermore, I think that Lua is even more difficult to parse because it uses <code>end</code> for all those things, but doesn't use <code>begin</code> (like Pascal does). When parsing Lua, you basically need to keep track of all <code>do</code>-es and <code>then</code>-es at the same time. Whereas, when parsing AEC, you can first deal with <code>Then</code>-es and <code>EndIf</code>-es, and then, after you have done that, deal with <code>Loop</code>-es and <code>EndWhile</code>-es.</p>
<p>The other obvious answer is that <code>}</code> is easier to type than <code>EndIf</code>. But I am also not sure that's the case. I am Croatian, and I don't even know where <code>}</code> is on the Croatian keyboard. If I were forced to use the Croatian keyboard, it would be much easier for me to type <code>EndIf</code> than to type <code>}</code>.</p>
<p>I think using different tokens for <code>EndIf</code> and <code>EndWhile</code> makes the code significantly easier to read by humans. But maybe I am biased, since SmallBasic was my first programming language. What do you think?</p>

<syntax><parsing>
Why do most languages use the same token for `EndIf`, `EndWhile`, `EndFunction` and `EndStructure`?
CC BY-SA 4.0
2023-07-03T00:16:03.277Z
The obvious answer to me would be that `End` is easier to type than `EndFunction` or `EndStructure`. Another useful point of comparison might be HTML/XML, where each opening tag must be matched by a closing tag which includes the tag's name; I think many people don't like editing HTML or XML by hand, because it's so verbose.
kaya3
CC BY-SA 4.0
2023-07-03T01:11:23.133Z
See also TeX `\begin{foo}` … `\end{foo}`.
Bbrk24
CC BY-SA 4.0
2023-07-03T01:54:37.133Z
A case regarding readability: rust-analyzer (an LSP server for Rust) can add inlay hints (a kind of virtual annotation), and one of them is at the end of long functions like `} // fn fn_name`. But it does that only on long functions (25+ lines, configurable), and does *not* do that on `if`/`for`/`loop`/...s (all of which also end with `}`).
Bubbler
CC BY-SA 4.0
2023-07-03T09:10:40.363Z
By the way, a quick google says that on Croatian keyboards you should be able to easily type `{` with either `Ctrl + Alt + B` or `AltGr + B`. (AltGr is the right Alt key). And with `N` for `}`
Ivo
CC BY-SA 4.0
2023-07-03T09:52:31.450Z
"...very few languages use the same token for all those things."  I think you mean "very few languages use **different** tokens for all those things."
Ari Brodsky
CC BY-SA 4.0
2023-07-03T10:01:53.140Z
Regarding the Croatian keyboard and ease of typing. Regrettably, I think that is rarely if ever a consideration for those designing languages. Nearly all languages restrict themselves to characters that are easy to type on old US keyboards and have little other consideration.
Jack Aidley
CC BY-SA 4.0
2023-07-03T16:51:26.457Z
(Quite a few other languages use different tokens, e.g. AppleScript, bash and other shells, and other dialects of BASIC.)
gidds
CC BY-SA 4.0
2023-07-03T20:10:06.327Z
"I think using different tokens for EndIf and EndWhile makes the code significantly easier to read by humans." What matters, IMHO, is people _writing_ code. As long as people write useful programs in a language, that language will live; if not, it dies. So the question could be: is it easier for the programmer to write different tokens, or have one general purpose End?
Every programming language looks beautiful to the people who begat it, so they will write some sot of compiler/interpreter. Ease of parsing doesn't matter, unless the language is impossible to parse.
Simon Crase
CC BY-SA 4.0
2023-07-04T02:09:15.063Z
(Don’t forget the lisp family :)
D. Ben Knoble
CC BY-SA 4.0
2024-03-16T21:26:08.273Z
I'm a left-handed touch typist. For me, } is the most difficult key on the entire standard US keyboard -- worst finger, worst hand,  worst position (even the edge key is easier to find) FORTRAN was a language built for typists. C was a language built for non-typists doing their own keyboarding (No keypunch operators).
david
CC BY-SA 4.0
2024-05-14T17:12:26.207Z
C, for example, makes specific provision for restricted keyboards by supporting [trigraphs](https://en.wikipedia.org/wiki/Digraphs_and_trigraphs_(programming)#C): for example, `??<` and `??>` can be used in place of `{` and `}` resp.  (I've never seen them used in the wild, though.  I expect that key mappings — as described in an earlier comment — or editor macros are plenty good enough for most folk.)
gidds
CC BY-SA 4.0
2024-05-14T17:15:47.980Z
@david Remember that code is read much more often than it's written.  So it can be worth making something a little more awkward to type, if it significantly improves readability.  — Having said, that, I too am a touch-typist, and over the many years I wrote C, I didn't find braces to be a problem.  (Hashes were worse.  Though the most awkward key is the Esc key that you need pretty frequently if you use vi/vim!)
gidds
CC BY-SA 4.0
2024-09-17T22:13:09.327Z
I think most people either get used to Escape (since you don't really need to be able to type it at speed, especially when switching between modes), or you remap what it does to something easier to type (`jk` seems popular, though retraining myself to use it never worked out).
chepner
<p>It is not used in most language because indentation makes the extra information in <code>endX</code> statements redundant noise.</p>
<p>In a bit of code that looks like this (please imagine that but ten times as long and twice as nested for the full effect):</p>
<pre><code>if (██████) {
while(██████){
██████
██████
██████
// ██████
██████
}
for(██████; ██████; ██████) {
if (██████) ██████;
██████
██████
}}
</code></pre>
<p>Markers to indicate which <code>end</code> or <code>}</code> refers to what would be very useful but programmers don't write code like that. They indent their code to indicate what matches with what that and makes the additional information become redundant. Moreover, (as per @BoppreH's elegant demonstration in <a href="https://langdev.stackexchange.com/a/1920/883">another answer</a>) the additional text is more easily confused with the other syntactic markers and so actually makes the code harder to read.</p>
<p>Since indentation, whilst not mandatory in most languages, is expected behaviour of programmers these days - and has been for a long time now - any benefit of having individually tagged end markers is lost.</p>

CC BY-SA 4.0
2023-07-03T11:14:01.477Z
2023-07-03T11:14:01.477Z
Jack Aidley
CC BY-SA 4.0
2023-07-05T17:34:52.757Z
"Programmers don't write code like that"--unfortunately, some of them do. You should see some of the Java code I have to work with. :P
DLosc
<h3>Improving readability by reducing word count</h3>
<p>(alternatively: it's easier for <em>humans</em> to parse)</p>
<p>Reading source code is hard, and syntax has a big impact on one's ability to skim and search. The most infamous examples are line noise by abusing operators (<a href="https://www.perlmonks.org/?node_id=82635" rel="noreferrer"><code>s()/#?=&gt;$&quot;:}\~&gt;\\!;/;</code></a>, anyone?), but I'd argue that <em>wordy</em> syntax is also bad.</p>
<p>I made a fake piece of code using AEC blocks:</p>
<pre><code>Structure ██████ Consists Of
    ███ ████
    ███ ██████
EndStructure

Function ███(█████, ███, ██) Which Returns ███ Does
    If ████████ Then
        If ███████ █████ Then
             ██████████
             ████████
             Return ██████
        EndIf

        ████████
        █████████
        ██████
    EndIf

    ██████████
    While ████████ Loop
        ████████
        If █████ Then
            █████
        EndIf
    EndWhile
EndFunction
</code></pre>
<p>And the same code with C blocks:</p>
<pre><code>struct ██████ {
    ███ ████
    ███ ██████
}

███ ███(█████, ███, ██) {
    if (████████) {
        if (███████ █████) {
             ██████████
             ████████
             return ██████
        }

        ████████
        █████████
        ██████
    }

    ██████████
    while (████████) {
        ████████
        if (█████)
            █████
    }
}
</code></pre>
<p>When reading code I can easily ignore all the <code>{ }</code> because they are small and redundant with good indentation. But the wordy <code>Consists Of</code>, <code>EndStructure</code>, etc, are too similar to variable names and comments, making it harder to focus on the important bits.</p>
<p>You could run an experiment with two fake languages with either block style. I'd expect that volunteers can search <code>{ }</code>-based code quicker than the wordy tokens.</p>
<hr />
<p>Your point about keyboard layouts is still relevant. I paid extra to have my keyboard in US-layout instead of German, otherwise typing <code>{}[]</code> requires altgr+number keys (?!). If you can think of block delimiters that don't hurt readability <em>and</em> are easier to type, they may make a good alternative, even if they break convention.</p>

CC BY-SA 4.0
2023-07-03T10:08:48.967Z
2023-07-03T12:22:17.870Z
2023-07-03T12:22:17.870Z
BoppreH
CC BY-SA 4.0
2023-07-03T13:10:18.477Z
I think the ubiquity of syntax highlighting makes a difference to this. It would have been much more significant at the time C was designed, though.
kaya3
CC BY-SA 4.0
2023-07-03T21:05:12.420Z
I think this is the real strongest argument against scope-ending keywords. And I say that, even though Basic was my first language too. Actual *words*, with *letters*, that I need to *read*, is too much a price to pay for what is conceptually a big pencil-drawn circle around some code.
Eldritch Conundrum
CC BY-SA 4.0
2023-07-04T01:01:15.787Z
At the time C was designed, keywords were standard in mainstream languages such as Fortran, PL/I, and Algol. But also remember that at the time, programs were mostly read on actual paper, printed out on teletype terminals. CRT terminals wouldn't get bold text until the mid 1970s.
Pseudonym
CC BY-SA 4.0
2023-07-04T11:30:05.887Z
I think it was in TurboPascal that an alternative to "{ block code }" was "(. block code .)".
Niels Holst
CC BY-SA 4.0
2023-07-04T11:51:35.737Z
According to this logic, APL would be the most readable language there is. Alas, it isn't. At best, it is as readable as any other language and my personal bias is simply a matter of experience (which does not include APL, hence I find it difficult to read). But I think that keywords are actually *better* readable than special characters. C like syntax is so familiar to us that we mistakenly consider it readable, which it really isn't.
Peter - Reinstate Monica
CC BY-SA 4.0
2023-07-04T16:48:46.010Z
It is interesting that you say that keywords are more *readable*.  I don't necesarily disagree.  But when I look at code (whether it's C/C++ or Lisp) I don't actually *read* the delimiters.  I see them, but I don't read them.  They usually only consciously register if they look wrong.  Rather like punctuation in natural language text.  I find having keywords (especially different ones) for delimiters about as hard to read as natural language would be with the punctuation spelled out as words.
Paul
CC BY-SA 4.0
2023-07-04T19:39:17.053Z
@NielsHolst A... cleavage-delimited code block?
T. Sar
CC BY-SA 4.0
2023-07-04T20:25:04.427Z
@Peter-ReinstateMonica I'd say the point is not so much that keywords and identifiers should be as short as possible. Words contain information that _can_ be useful for readability, though there are limits... Cobol anyone? The actual point is that specifically the `EndFoo` the information contain only redundant information, and therefore add nothing that would really help readability but only noise.
leftaroundabout
CC BY-SA 4.0
2023-10-30T20:25:28.827Z
@NielsHolst: In PASCAL, `(.` and `.)` were digraph synonyms for `[` and `]`, and `(*` and `*)`  were synonyms for `{` and `}`.
supercat
<p>The reason most languages use <code>}</code> is C did it that way.</p>

CC BY-SA 4.0
2023-07-03T00:18:23.173Z
2023-07-03T00:18:23.173Z
Alexis King
CC BY-SA 4.0
2023-07-03T11:06:28.633Z
But why did C do it that way, and why did so many people consider it such a good idea that they used in their own programming languages?
Philipp
CC BY-SA 4.0
2023-07-03T11:51:39.340Z
@Philipp C does it that way because B does it that way :-)
Mark Morgan Lloyd
CC BY-SA 4.0
2023-07-03T20:17:50.250Z
@Philipp C was born in 1972. I assume that Kernighan & Ritchie would have used the same type of terminal that I used during the early 1970s, an [ASR35 teletype](https://www.blunham.com/Misc/ASR35/). If I have been offered a choice between two languages, which used _{...}_ and _begin...end_, I know which one I'd have gone for.
Simon Crase
CC BY-SA 4.0
2023-07-04T04:22:58.827Z
@Philipp Why C did it that way is essentially irrelevant. C could have picked anything. The point is that C used it, and C was extremely popular and highly influential (for reasons unrelated to its syntax), so many modern languages are in some way descended from it, and many of them choose to use the same syntax.
Alexis King
CC BY-SA 4.0
2023-07-04T11:53:56.160Z
@Philipp If you use ink and paper via teletypes (or punch cards, or punched tape) to program, and if you count your mass storage in kB, every character counts. You strip off carriage returns, and you indicate blocks with single characters.
Peter - Reinstate Monica
CC BY-SA 4.0
2023-07-20T12:30:08.343Z
But perhaps C being extremely popular and highly influential is not _totally_ unrelated to its syntax!
Pablo H
CC BY-SA 4.0
2023-07-20T17:22:18.847Z
@PabloH Perhaps. But we have no evidence for that given the overwhelming other factors that led to its widespread adoption.
Alexis King
CC BY-SA 4.0
2024-03-16T21:29:38.097Z
If you used punch cards, you didn't even have a } character.  Which is why the trigraphs were part of the language definition. The reason c had the } character was because they were using CRT serial terminals, not punch cards.
david
CC BY-SA 4.0
2024-09-09T22:20:30.397Z
@AlexisKing: C was developed in an era where on-line program editing was the normal way of entering code, which meant it was desirable to minimize the number of characters required to express a construct.  Earlier languages dated to a time where the amount of space occupied by a program was based upon the number of lines (about six lines per cubic inch), independent of the amount of content on those lines, so a line with `END WHILE` would take no more space than a line with `}`, but when doing on-line editing character count matters.
supercat
CC BY-SA 4.0
2024-09-10T00:56:21.000Z
@supercat, CRTs were even more space-constrained than punch-cards in terms of what you could view at once. I suspect the perceived advantages of braces included the speed of (and unambiguity for) parsing, the reduction in visual clutter and in-keeping with the generally greater use of symbols, and ability to consolidate the open and close onto a single line (together with the two or more statements inside the block, the minimum to justify an explicit block being used at all) without causing excessive line length.
Steve
CC BY-SA 4.0
2024-09-10T14:37:22.360Z
@Steve: CRTs would favor minimizing the number of lines (something C allowed, but FORTRAN didn't), but could fit a line full of content just as easily as a line containing nothing but a brace character.  Using a teletype (paper or glass), however, the time required to display a long line would be greater than that for a short line, whereas most FORTRAN-era printers would on average take longer to output a line containing a single brace than a line containing only uppercase alphanumerics.
supercat
<p>As another answer says, labeling the end constract would be mostly redundant. It would only have semantic value if you allow ending multiple blocks with a single end, e.g.</p>
<pre><code>IF ...
    WHILE ...
        body
ENDIF
</code></pre>
<p>In the above, <code>ENDWHILE</code> can be omitted because <code>ENDIF</code> implicitly closes all blocks contained in it.</p>
<p>The only language I can think of where this style is used is HTML. Some tags are automatically closed in some contexts (e.g. you can omit <code>&lt;/option&gt;</code> before the next <code>&lt;option&gt;</code>). And HTML parsers will also auto-close some tags even when the language doesn't permit it, to implement the <a href="https://en.wikipedia.org/wiki/Robustness_principle" rel="noreferrer">robustness principle</a>.</p>
<p>In a language without distinct end tokens, you can always use a comment to help link the end to the beginning when you write large blocks. But blocks large enough to need this are also generally considered poor coding style. So we don't want to encourage it with language design that makes it easier.</p>

CC BY-SA 4.0
2023-07-03T15:20:28.350Z
2023-07-03T15:20:28.350Z
Barmar
<p>I did want to point out that Turbo Pascal was no innovator when it came to <code>(*</code> and <code>*)</code> substituting for braces.  Those digraphs are what I had to use when learning Pascal in 1979 on our Hollerith punched-card mainframe, which used EBCDIC internally, which doesn't even <em>have</em> the brace characters.</p>
<p>Languages that predate the ubiquity of ASCII would certainly be biased towards keywords rather than punctuation for blocking.</p>
<p>Languages developed on slow mechanical I/O devices (punched cards or ASR33 TTY's) would be biased towards shorter rather than longer sequences.  They also would not want to care about indention, because re-punching a bunch of cards just because you added an IF in front of them would be a maddening waste of time and materials.  Not to mention the risk of running into the maximum width of a punched card.</p>
<p>These early languages would then have set the stage for their descendants.</p>

CC BY-SA 4.0
2024-09-09T18:06:48.800Z
2024-09-09T19:02:50.010Z
2024-09-09T19:02:50.010Z
jimc
CC BY-SA 4.0
2024-09-10T14:40:44.353Z
An interesting difference between FORTRAN-era printing devices and those of C's inventors is that the time required to output a line on the former would depend upon the "rarest" character on the chain (many chains would have alphanumerics repeated something like five times, but characters like braces only once), so the chain would have to make at most 1/5 of a revolution to print all of the alphanumerics on a line, but on average half a resolution to output even a single brace character.
supercat
CC BY-SA 4.0
2024-10-02T18:03:42.723Z
The TTY40 we used back in the day had two chains: uppercase-only and mixed case.  The UC chain had 5 (?) sets of characters on it, the ULC chain had 3.  The former printed listings noticeably faster than the latter, and since listings were all these printers were used for, the fleet was exclusively UC.  (I have a ULC chain on my personal TTY40 that I acquired many years ago.  I can't remember the last time I fired it up.  Laser printers ate chain printers' lunches when they came out.)
jimc
<p>The original ALGOL way was that where an explicit END was needed the next token- or at least sometimes the remainder of the card- was treated as a comment.</p>
<p>Hence from Burroughs B5500 ALGOL:</p>
<pre><code>...
    END IF
  END IF % ANYTHING AFTER END IS IGNORED HERE.                                 %
END.     % END MUST BE FOLLOWED IMMEDIATELY BY . HERE ------------------------ %
</code></pre>
<p>Derivative languages either dropped provision for an unparsed comment (i.e. any comment had to be marked explicitly), or merged the commonly-used comments into the token (i.e. END IF became ENDIF).</p>
<p>Somewhat later I've realised that I've misread the question. I think OP intended to ask &quot;why do most languages use END rather than ENDIF, ENDWHILE etc.&quot; but instead I focused on the ENDsomething aspect.</p>
<p>I'll leave my answer undeleted in the unlikely case that there's something of historical interest in it.</p>

CC BY-SA 4.0
2023-07-03T12:01:44.870Z
2023-07-03T17:26:55.380Z
2023-07-03T17:26:55.380Z
Mark Morgan Lloyd
<p>I think your language AEC is really quite interesting.</p>
<p>When it comes to programming languages, there are two main philosophies.</p>
<p>One is drawn from those who prefer natural language (invariably English), the other is drawn from those who prefer symbols. Each has its arguments and its areas of application.</p>
<p>It isn't found strictly necessary to have a special end token in block-structured languages, whether they be English-like or symbol-like. That's essentially how you get as far as Pascal with it's generic <code>begin</code> and <code>end</code> tokens.</p>
<p>In all languages, but especially in the English-style ones, there's a need to balance economy and clarity.</p>
<p>Research shows that people don't read letter-by-letter like computers process strings. When possible, they recognise whole shapes in a gestalt fashion - this applies generally, including applying to words, to sentences, and to blocks.</p>
<p>In English-like languages that have the potential to be almost infinitely verbose, keeping things as short as possible is still quite desirable, to avoid visual clutter and facilitate shape recognition.</p>
<p>So in principle, for those designing a programming language in a rational fashion, <code>end</code> is a perfectly good token. There isn't a need, at first, to justify why it isn't longer, because short is good.</p>
<p>However, experience shows that two situations are not uncommon. The first is to have several levels of blocks nested. The second is to have blocks longer than what can be shown on the screen. And both of these cases occur often enough together even.</p>
<p>Visual Basic (as an example of an English-like language I know well) further helps these situations in two ways. Firstly, it has special keywords to terminate a block which are different depending on the type of block. Secondly, with certain blocks (like <code>For</code>) where the same type of block is commonly nested, you can identify the block by the variable name.</p>
<pre><code>For i = 1 To 5
    For j = 1 To 3
    ...
    Next j
Next i
</code></pre>
<p>I'm a regular user of SQL, and it's not uncommon nowadays for single statements (when consistently formatted) to run over several pages on screen, and for blocks to reach several levels deep when writing complicated procedures. Towards the end of a procedure, there is then a series of:</p>
<pre><code>            end;
        end;
    end;
end;
</code></pre>
<p>In these cases, I miss VB's special block-ending keywords. And I agree that Pascal (and languages which follow it in this respect, like SQL) is deficient, and that repeating the block type at the end token is found to be a generally useful feature of a language, and it would be more desirable to have a syntax something like so instead:</p>
<pre><code>            end if;
        end while;
    end if;
end procedure;
</code></pre>

CC BY-SA 4.0
2023-09-23T18:46:01.520Z
2023-09-23T18:46:01.520Z
Steve
CC BY-SA 4.0
2024-09-09T20:51:57.457Z
To make up for not having `end if` and `end while`, many programmers in C-style languages will put the starting keyword in a comment: `end /* if */;`
Barmar
CC BY-SA 4.0
2024-09-09T21:04:29.810Z
@Barmar, yes I do so myself!
Steve
<p>There are four broad approaches on how to put a block of code inside a control structure in a block-structured language.</p>
<h2>The Algol Way</h2>
<p>In the Algol way, each control structure has its own way to &quot;close&quot; the body. In Algol, specifically, you spell the opening word backwards:</p>
<pre><code>IF  3 = input THEN
   # Do something #
FI;

CASE input IN
    ~ # Do something, because input = 1 #
  ,
    ~ # Do something, because input = 2 #
  ,
    ~ # Do something, because input = 3 #
  ,
    # fall through to the next statement IF there is no &quot;OUT&quot; #
  OUT
    ~ # Do something ELSE. #
ESAC
</code></pre>
<p>Fortran uses something similar, using the keyword <code>end</code> followed by the type of construct that it ends:</p>
<pre><code>IF logical-expression THEN
   statements-1
ELSE
   statements-2
END IF
</code></pre>
<h2>The Pascal Way</h2>
<p>In the Pascal way, the body of a control structure is a single statement. Note that there is no &quot;endif&quot; token as part of the control structure's syntax:</p>
<pre class="lang-pascal prettyprint-override"><code>if logical-expression then
    single-statement-1
else
    single-statement-2
</code></pre>
<p>However, a statement can be a block. In Pascal, blocks are denoted by <code>begin</code> and <code>end</code>. So the <code>end</code> token delimits the block, not the <code>if</code> statement which contains the block.</p>
<pre class="lang-pascal prettyprint-override"><code>if logical-expression then
  begin
    statements-1
  end
else
  begin
    statements-2
  end
</code></pre>
<p>C also uses this syntax, but blocks are denoted by <code>{</code> and <code>}</code>.</p>
<pre class="lang-c prettyprint-override"><code>if (logical-expression)
    statement-1
else
    statement-2

if (logical-expression) {
    statements-1
} else {
    statements-2
}
</code></pre>
<p>Note that C does not have a <code>then</code> keyword, and so conditions are surrounded by parentheses to ensure that the condition is separate from the body.</p>
<h2>The Perl Way</h2>
<p>In C, the parentheses around the logical expression are not part of the expression's syntax, they are part of the control structure's syntax. Similarly, you can make the block begin/end markers part of the control structure. This is how Perl does it.</p>
<p>An if-then-else statement in Perl has this syntax:</p>
<pre class="lang-perl prettyprint-override"><code>if (logical-condition) {
   statements-1
} else {
   statements-2
}
</code></pre>
<p>Even if you only want a single statement in the body of an if-then-else, the braces <em>must</em> be included, because they are part of the <code>if</code> statement's syntax. The same is true in Rust, where braces are a required part of the syntax for <code>if</code>, <code>while</code> and some other control-flow statements.</p>
<p>However, Perl does allow you to omit braces for a single statement if you use a &quot;reversed&quot; syntax:</p>
<pre class="lang-perl prettyprint-override"><code># This IS NOT valid Perl
if (x &lt; 2) do_something();

# This IS valid Perl.
do_something()  if x &lt; 2;
</code></pre>
<p>Perl's approach has a very counter-intuitive implication. Perl has the control statements <code>next</code>, <code>last</code>, and <code>redo</code> which let you jump around a loop similar to <code>break</code> in C.</p>
<pre class="lang-perl prettyprint-override"><code>while (&lt;STDIN&gt;) {
    # This statement compares the line read from STDIN against
    # the regular expression /^$/. If it matches, exit the loop.
    last  if /^$/;
    statements
}
</code></pre>
<p>However, this <code>last</code> keyword only applies to <em>loops</em>. You can't jump to the end of the body of a then:</p>
<pre class="lang-perl prettyprint-override"><code>if (x &lt; 2) {
    some statements
    # The following statement jumps to the end of any
    # enclosing loop, not to the end of the if statement.
    last  if y &gt; 3;
    some more statements
}
</code></pre>
<p>You can get the effect you want by naming a block:</p>
<pre class="lang-perl prettyprint-override"><code>LABEL: {
    if (x &lt; 2) {
        some statements
        # The following statement jumps to the end of the
        # named block.
        last LABEL  if y &gt; 3;
        some more statements
    }
}
</code></pre>
<p>However, in this case, you don't need the labels. A pair of curly braces that are <em>not</em> part of a control statement (i.e. just a block) has the semantics of a loop that executes exactly once. So either of these will also work:</p>
<pre class="lang-perl prettyprint-override"><code># This outer pair of braces is, semantically, a run-once loop.
{
    if (x &lt; 2) {
        some statements
        # This statement jumps to the end of the enclosing loop.
        last  if y &gt; 3;
        some more statements
    }
}

# The same as above, only the run-once loop is inside the &quot;then&quot; part.
if (x &lt; 2) {{
    some statements
    last  if y &gt; 3;
    some more statements
}}

</code></pre>
<p>I don't know of any other languages which have gone with Perl's approach. It seems a little difficult to explain.</p>
<h2>The Occam Way</h2>
<p>Occam uses whitespace to denote blocks.</p>
<pre><code>IF
  x &gt; y
    order := gt
  x &lt; y
    order := lt
  TRUE
    order := eq
</code></pre>
<p>Python's syntax takes cues from Occam, but be aware that Python is not a block-structured language in the usual sense of that term; blocks are not variable scopes in Python.</p>

CC BY-SA 4.0
2023-07-03T01:16:27.560Z
2023-07-03T01:53:48.717Z
2023-07-03T01:53:48.717Z
Pseudonym
CC BY-SA 4.0
2023-07-03T04:18:44.533Z
This is a great answer on approaches to block structure syntax but does not answer the main question of why most languages use a generic token for ending blocks.
kouta-kun
CC BY-SA 4.0
2023-07-03T05:33:03.640Z
@kouta-kun I'm not sure that "most languages" do. But the underlying point is that if you are a block-structured language, you can either come up with one lexical syntax for delimiting blocks, or a different one for each kind of block. If you're going to pick the former, it's inevitably either going to be words like begin/end, or some syntax that resembles bracketing (i.e. [ ], ( ), < >, or { }).
Pseudonym
CC BY-SA 4.0
2023-07-03T10:26:58.050Z
+1 for @kouta-kun's comment. Without focusing on popularity, this is a "why" question, but this answer doesn't explain why one would choose one block-style over another.
BoppreH
CC BY-SA 4.0
2023-07-03T11:50:21.687Z
While "reverse spelling" might have been an ALGOL-68 thing, I don't think it was an ALGOL-60 thing.
Mark Morgan Lloyd
CC BY-SA 4.0
2023-07-03T15:09:20.400Z
This is a nice survey of all the styles, but doesn't really answer the "why" question. If each style included a pros and cons, it would approach that answer.
Barmar
CC BY-SA 4.0
2023-07-03T15:39:36.623Z
The Bourne shell (and its derivatives like `bash` and `zsh`) uses the Algol way — except that the end of a loop is `done` instead of `od`, due to `od` being the Octal Dump utility.
dan04
CC BY-SA 4.0
2023-07-03T17:26:06.093Z
The Algol-68 ideas of `fi` and `esac` etc seem find as a start, but they are less convenient when spelling `procedure` or `function` backwards.
AdrianHHH
CC BY-SA 4.0
2023-07-04T02:10:15.003Z
As on the OP: (don’t forget the lisp family :)
D. Ben Knoble
CC BY-SA 4.0
2023-07-04T02:15:53.570Z
Lisp isn't a block structured language. Nor is Prolog, for that matter.
Pseudonym
CC BY-SA 4.0
2023-07-04T21:18:57.307Z
It does explain it,@kouta-kun, albeit indirectly.  Languages such as the BASIC family have distinct types of blocks for use with different language features; these languages allow you to, e.g., use either a block or a single statement as the "then" part of an `if ... then` conditional.  Languages that use the Pascal style or similar instead _only_ allow a single statement as the "then" part of said conditional, because the language itself allows "code block" to be treated as a single statement.  (To be continued.)
Justin Time - Reinstate Monica
CC BY-SA 4.0
2023-07-04T21:19:08.010Z
As a result, there's no need for an explicit `block if ... then` construct, because single-statement `if ... then` implicitly allows the "code block" single statement.  In effect, the existence of a language construct which allows a group of statements to be treated as a single statement regardless of context, the generic code block, removes the need for language constucts which introduce their own type of code block, and removes the need to differentiate between single-statement and block versions of language constructs.
Justin Time - Reinstate Monica
CC BY-SA 4.0
2023-07-04T21:25:09.237Z
Basically, @kouta-kun, think about it like peripheral ports.  Originally, there were keyboard ports, and serial ports, and parallel ports, and PS/2 ports, and game ports, plus whatever else a specific manufacturer might come up with.  But then, they invented USB, and everyone started using it instead, and the other ports mostly disappeared because there wasn't any need for them anymore.  What Pseudonym is getting at here is that Pascal essentially "invented USB", and as a result, there wasn't any need for each control structure to have its own "peripheral port", so to speak.
Justin Time - Reinstate Monica
CC BY-SA 4.0
2023-07-05T00:05:12.030Z
@JustinTime-ReinstateMonica That's not a terrible analogy, but that's not entirely correct about Pascal being the first to use one keyword or punctuation mark to end blocks. FLOW-MATIC used semicolons to break statements in a group and a full stop/period to end the group, analogous to English punctuation. Cobol still carries that legacy. But FLOW-MATIC wasn't block-structured.
Pseudonym
CC BY-SA 4.0
2023-07-05T10:09:50.707Z
@BoppreH This is a "why" answer, specifically it explains that many languages have a uniform block structure/construct and therefore all blocks look the same no matter where they appear. The answer does not look at the _motivation_ for a uniform block structure, which you may find unsatisfying, but it does answer the question.
Matthieu M.
CC BY-SA 4.0
2023-07-05T22:07:10.187Z
Oh, that's interesting, @Pseudonym.  I wasn't aware of the full history there, I just assumed Pascal originated it because you labeled generic blocks "the Pascal way".  I guess Pascal would be the most notable early example, then (presumably because it actually used block structure), if you name generic blocks after it rather than FLOW-MATIC?
Justin Time - Reinstate Monica
CC BY-SA 4.0
2023-07-06T00:27:04.760Z
@JustinTime-ReinstateMonica The thing about FLOW-MATIC is that it wasn't block-structured. It was more like 1980s-era BASIC, in that you could separate statements on one line. I think PL/I was actually the first, but it used DO/END rather than BEGIN/END, and that would have complicated the examples because people might think DO starts a DO/WHILE.
Pseudonym
CC BY-SA 4.0
2023-07-08T00:42:01.323Z
Ah, I see, @Pseudonym, that makes sense.  Thanks for the programming language history lesson!
Justin Time - Reinstate Monica
CC BY-SA 4.0
2023-10-18T14:28:30.040Z
There are also hybrids.  For example, in AppleScript you can use specific terminators `end if`, `end repeat`, `end tell`, etc. — or you can just put `end` for all of them.  (In the latter case, the Script Editor automatically fills in the specific token when it compiles/runs a script — but scripts run outside it fine with only `end`.)
gidds
# Why do most languages use the same token for `EndIf`, `EndWhile`, `EndFunction` and `EndStructure`?
Posted by: username_0 on 2023-07-03
In my programming language, [AEC](https://flatassembler.github.io/AEC_specification), I am using keywords `EndIf` and `EndWhile` with the same meaning as in SmallBasic, and I am also using `EndFunction` (corresponding to `EndSub` in SmallBasic) and `EndStructure` (for ending the structures). But I have noticed very few languages use different tokens for those things. Of the programming languages I know, only SmallBasic, Ada and VHDL (with a syntax based on Ada) distinguish those things. Most programming languages I know use `}` for all of those things, and those that do not (such as Pascal or MatLab or Lua) use `end` for all of those. Why?

An obvious answer is that using the same token for all those things makes the programming language slightly easier to parse. But I think that cannot be the main reason. Furthermore, I think that Lua is even more difficult to parse because it uses `end` for all those things, but doesn't use `begin` (like Pascal does). When parsing Lua, you basically need to keep track of all `do`-es and `then`-es at the same time. Whereas, when parsing AEC, you can first deal with `Then`-es and `EndIf`-es, and then, after you have done that, deal with `Loop`-es and `EndWhile`-es.

The other obvious answer is that `}` is easier to type than `EndIf`. But I am also not sure that's the case. I am Croatian, and I don't even know where `}` is on the Croatian keyboard. If I were forced to use the Croatian keyboard, it would be much easier for me to type `EndIf` than to type `}`.

I think using different tokens for `EndIf` and `EndWhile` makes the code significantly easier to read by humans. But maybe I am biased, since SmallBasic was my first programming language. What do you think?
**Tags:** syntax parsing
> **Comments:**
> **username_1**: The obvious answer to me would be that `End` is easier to type than `EndFunction` or `EndStructure`. Another useful point of comparison might be HTML/XML, where each opening tag must be matched by a closing tag which includes the tag's name; I think many people don't like editing HTML or XML by hand, because it's so verbose.  
> **username_2**: See also TeX `\begin{foo}` … `\end{foo}`.  
> **username_3**: A case regarding readability: rust-analyzer (an LSP server for Rust) can add inlay hints (a kind of virtual annotation), and one of them is at the end of long functions like `} // fn fn_name`. But it does that only on long functions (25+ lines, configurable), and does *not* do that on `if`/`for`/`loop`/...s (all of which also end with `}`).  
> **username_4**: By the way, a quick google says that on Croatian keyboards you should be able to easily type `{` with either `Ctrl + Alt + B` or `AltGr + B`. (AltGr is the right Alt key). And with `N` for `}`  
> **username_5**: "...very few languages use the same token for all those things."  I think you mean "very few languages use **different** tokens for all those things."  
> **username_6**: Regarding the Croatian keyboard and ease of typing. Regrettably, I think that is rarely if ever a consideration for those designing languages. Nearly all languages restrict themselves to characters that are easy to type on old US keyboards and have little other consideration.  
> **username_7**: (Quite a few other languages use different tokens, e.g. AppleScript, bash and other shells, and other dialects of BASIC.)  
> **username_8**: "I think using different tokens for EndIf and EndWhile makes the code significantly easier to read by humans." What matters, IMHO, is people _writing_ code. As long as people write useful programs in a language, that language will live; if not, it dies. So the question could be: is it easier for the programmer to write different tokens, or have one general purpose End?
Every programming language looks beautiful to the people who begat it, so they will write some sot of compiler/interpreter. Ease of parsing doesn't matter, unless the language is impossible to parse.  
> **username_9**: (Don’t forget the lisp family :)  
> **username_10**: I'm a left-handed touch typist. For me, } is the most difficult key on the entire standard US keyboard -- worst finger, worst hand,  worst position (even the edge key is easier to find) FORTRAN was a language built for typists. C was a language built for non-typists doing their own keyboarding (No keypunch operators).  
> **username_7**: C, for example, makes specific provision for restricted keyboards by supporting [trigraphs](https://en.wikipedia.org/wiki/Digraphs_and_trigraphs_(programming)#C): for example, `??<` and `??>` can be used in place of `{` and `}` resp.  (I've never seen them used in the wild, though.  I expect that key mappings — as described in an earlier comment — or editor macros are plenty good enough for most folk.)  
> **username_7**: @david Remember that code is read much more often than it's written.  So it can be worth making something a little more awkward to type, if it significantly improves readability.  — Having said, that, I too am a touch-typist, and over the many years I wrote C, I didn't find braces to be a problem.  (Hashes were worse.  Though the most awkward key is the Esc key that you need pretty frequently if you use vi/vim!)  
> **username_11**: I think most people either get used to Escape (since you don't really need to be able to type it at speed, especially when switching between modes), or you remap what it does to something easier to type (`jk` seems popular, though retraining myself to use it never worked out).  
---
## 8 answers
### Answer by username_15 on 2023-07-03. Score: 36 | Accepted answer
There are four broad approaches on how to put a block of code inside a control structure in a block-structured language.
The Algol Way
In the Algol way, each control structure has its own way to "close" the body. In Algol, specifically, you spell the opening word backwards:
IF  3 = input THEN
   # Do something #
FI;

CASE input IN
    ~ # Do something, because input = 1 #
  ,
    ~ # Do something, because input = 2 #
  ,
    ~ # Do something, because input = 3 #
  ,
    # fall through to the next statement IF there is no "OUT" #
  OUT
    ~ # Do something ELSE. #
ESAC

Fortran uses something similar, using the keyword end followed by the type of construct that it ends:
IF logical-expression THEN
   statements-1
ELSE
   statements-2
END IF

The Pascal Way
In the Pascal way, the body of a control structure is a single statement. Note that there is no "endif" token as part of the control structure's syntax:
if logical-expression then
    single-statement-1
else
    single-statement-2

However, a statement can be a block. In Pascal, blocks are denoted by begin and end. So the end token delimits the block, not the if statement which contains the block.
if logical-expression then
  begin
    statements-1
  end
else
  begin
    statements-2
  end

C also uses this syntax, but blocks are denoted by { and }.
if (logical-expression)
    statement-1
else
    statement-2

if (logical-expression) {
    statements-1
} else {
    statements-2
}

Note that C does not have a then keyword, and so conditions are surrounded by parentheses to ensure that the condition is separate from the body.
The Perl Way
In C, the parentheses around the logical expression are not part of the expression's syntax, they are part of the control structure's syntax. Similarly, you can make the block begin/end markers part of the control structure. This is how Perl does it.
An if-then-else statement in Perl has this syntax:
if (logical-condition) {
   statements-1
} else {
   statements-2
}

Even if you only want a single statement in the body of an if-then-else, the braces must be included, because they are part of the if statement's syntax. The same is true in Rust, where braces are a required part of the syntax for if, while and some other control-flow statements.
However, Perl does allow you to omit braces for a single statement if you use a "reversed" syntax:
# This IS NOT valid Perl
if (x < 2) do_something();

# This IS valid Perl.
do_something()  if x < 2;

Perl's approach has a very counter-intuitive implication. Perl has the control statements next, last, and redo which let you jump around a loop similar to break in C.
while () {
    # This statement compares the line read from STDIN against
    # the regular expression /^$/. If it matches, exit the loop.
    last  if /^$/;
    statements
}

However, this last keyword only applies to loops. You can't jump to the end of the body of a then:
if (x < 2) {
    some statements
    # The following statement jumps to the end of any
    # enclosing loop, not to the end of the if statement.
    last  if y > 3;
    some more statements
}

You can get the effect you want by naming a block:
LABEL: {
    if (x < 2) {
        some statements
        # The following statement jumps to the end of the
        # named block.
        last LABEL  if y > 3;
        some more statements
    }
}

However, in this case, you don't need the labels. A pair of curly braces that are not part of a control statement (i.e. just a block) has the semantics of a loop that executes exactly once. So either of these will also work:
# This outer pair of braces is, semantically, a run-once loop.
{
    if (x < 2) {
        some statements
        # This statement jumps to the end of the enclosing loop.
        last  if y > 3;
        some more statements
    }
}

# The same as above, only the run-once loop is inside the "then" part.
if (x < 2) {{
    some statements
    last  if y > 3;
    some more statements
}}


I don't know of any other languages which have gone with Perl's approach. It seems a little difficult to explain.
The Occam Way
Occam uses whitespace to denote blocks.
IF
  x > y
    order := gt
  x < y
    order := lt
  TRUE
    order := eq

Python's syntax takes cues from Occam, but be aware that Python is not a block-structured language in the usual sense of that term; blocks are not variable scopes in Python.
> **Comments:**
> **username_29** (2023-07-03): This is a great answer on approaches to block structure syntax but does not answer the main question of why most languages use a generic token for ending blocks.  
> **username_15** (2023-07-03): @kouta-kun I'm not sure that "most languages" do. But the underlying point is that if you are a block-structured language, you can either come up with one lexical syntax for delimiting blocks, or a different one for each kind of block. If you're going to pick the former, it's inevitably either going to be words like begin/end, or some syntax that resembles bracketing (i.e. [ ], ( ), < >, or { }).  
> **username_13** (2023-07-03): +1 for @kouta-kun's comment. Without focusing on popularity, this is a "why" question, but this answer doesn't explain why one would choose one block-style over another.  
> **username_24** (2023-07-03): While "reverse spelling" might have been an ALGOL-68 thing, I don't think it was an ALGOL-60 thing.  
> **username_27** (2023-07-03): This is a nice survey of all the styles, but doesn't really answer the "why" question. If each style included a pros and cons, it would approach that answer.  
> **username_30** (2023-07-03): The Bourne shell (and its derivatives like `bash` and `zsh`) uses the Algol way — except that the end of a loop is `done` instead of `od`, due to `od` being the Octal Dump utility.  
> **username_31** (2023-07-03): The Algol-68 ideas of `fi` and `esac` etc seem find as a start, but they are less convenient when spelling `procedure` or `function` backwards.  
> **username_9** (2023-07-04): As on the OP: (don’t forget the lisp family :)  
> **username_15** (2023-07-04): Lisp isn't a block structured language. Nor is Prolog, for that matter.  
> **username_32** (2023-07-04): It does explain it,@kouta-kun, albeit indirectly.  Languages such as the BASIC family have distinct types of blocks for use with different language features; these languages allow you to, e.g., use either a block or a single statement as the "then" part of an `if ... then` conditional.  Languages that use the Pascal style or similar instead _only_ allow a single statement as the "then" part of said conditional, because the language itself allows "code block" to be treated as a single statement.  (To be continued.)  
> **username_32** (2023-07-04): As a result, there's no need for an explicit `block if ... then` construct, because single-statement `if ... then` implicitly allows the "code block" single statement.  In effect, the existence of a language construct which allows a group of statements to be treated as a single statement regardless of context, the generic code block, removes the need for language constucts which introduce their own type of code block, and removes the need to differentiate between single-statement and block versions of language constructs.  
> **username_32** (2023-07-04): Basically, @kouta-kun, think about it like peripheral ports.  Originally, there were keyboard ports, and serial ports, and parallel ports, and PS/2 ports, and game ports, plus whatever else a specific manufacturer might come up with.  But then, they invented USB, and everyone started using it instead, and the other ports mostly disappeared because there wasn't any need for them anymore.  What Pseudonym is getting at here is that Pascal essentially "invented USB", and as a result, there wasn't any need for each control structure to have its own "peripheral port", so to speak.  
> **username_15** (2023-07-05): @JustinTime-ReinstateMonica That's not a terrible analogy, but that's not entirely correct about Pascal being the first to use one keyword or punctuation mark to end blocks. FLOW-MATIC used semicolons to break statements in a group and a full stop/period to end the group, analogous to English punctuation. Cobol still carries that legacy. But FLOW-MATIC wasn't block-structured.  
> **username_33** (2023-07-05): @BoppreH This is a "why" answer, specifically it explains that many languages have a uniform block structure/construct and therefore all blocks look the same no matter where they appear. The answer does not look at the _motivation_ for a uniform block structure, which you may find unsatisfying, but it does answer the question.  
> **username_32** (2023-07-05): Oh, that's interesting, @Pseudonym.  I wasn't aware of the full history there, I just assumed Pascal originated it because you labeled generic blocks "the Pascal way".  I guess Pascal would be the most notable early example, then (presumably because it actually used block structure), if you name generic blocks after it rather than FLOW-MATIC?  
> **username_15** (2023-07-06): @JustinTime-ReinstateMonica The thing about FLOW-MATIC is that it wasn't block-structured. It was more like 1980s-era BASIC, in that you could separate statements on one line. I think PL/I was actually the first, but it used DO/END rather than BEGIN/END, and that would have complicated the examples because people might think DO starts a DO/WHILE.  
> **username_32** (2023-07-08): Ah, I see, @Pseudonym, that makes sense.  Thanks for the programming language history lesson!  
> **username_7** (2023-10-18): There are also hybrids.  For example, in AppleScript you can use specific terminators `end if`, `end repeat`, `end tell`, etc. — or you can just put `end` for all of them.  (In the latter case, the Script Editor automatically fills in the specific token when it compiles/runs a script — but scripts run outside it fine with only `end`.)  
---
### Answer by username_13 on 2023-07-03. Score: 27
Improving readability by reducing word count
(alternatively: it's easier for humans to parse)
Reading source code is hard, and syntax has a big impact on one's ability to skim and search. The most infamous examples are line noise by abusing operators (s()/#?=>$":}\~>\\!;/;, anyone?), but I'd argue that wordy syntax is also bad.
I made a fake piece of code using AEC blocks:
Structure ██████ Consists Of
    ███ ████
    ███ ██████
EndStructure

Function ███(█████, ███, ██) Which Returns ███ Does
    If ████████ Then
        If ███████ █████ Then
             ██████████
             ████████
             Return ██████
        EndIf

        ████████
        █████████
        ██████
    EndIf

    ██████████
    While ████████ Loop
        ████████
        If █████ Then
            █████
        EndIf
    EndWhile
EndFunction

And the same code with C blocks:
struct ██████ {
    ███ ████
    ███ ██████
}

███ ███(█████, ███, ██) {
    if (████████) {
        if (███████ █████) {
             ██████████
             ████████
             return ██████
        }

        ████████
        █████████
        ██████
    }

    ██████████
    while (████████) {
        ████████
        if (█████)
            █████
    }
}

When reading code I can easily ignore all the { } because they are small and redundant with good indentation. But the wordy Consists Of, EndStructure, etc, are too similar to variable names and comments, making it harder to focus on the important bits.
You could run an experiment with two fake languages with either block style. I'd expect that volunteers can search { }-based code quicker than the wordy tokens.

Your point about keyboard layouts is still relevant. I paid extra to have my keyboard in US-layout instead of German, otherwise typing {}[] requires altgr+number keys (?!). If you can think of block delimiters that don't hurt readability and are easier to type, they may make a good alternative, even if they break convention.
> **Comments:**
> **username_1** (2023-07-03): I think the ubiquity of syntax highlighting makes a difference to this. It would have been much more significant at the time C was designed, though.  
> **username_14** (2023-07-03): I think this is the real strongest argument against scope-ending keywords. And I say that, even though Basic was my first language too. Actual *words*, with *letters*, that I need to *read*, is too much a price to pay for what is conceptually a big pencil-drawn circle around some code.  
> **username_15** (2023-07-04): At the time C was designed, keywords were standard in mainstream languages such as Fortran, PL/I, and Algol. But also remember that at the time, programs were mostly read on actual paper, printed out on teletype terminals. CRT terminals wouldn't get bold text until the mid 1970s.  
> **username_16** (2023-07-04): I think it was in TurboPascal that an alternative to "{ block code }" was "(. block code .)".  
> **username_17** (2023-07-04): According to this logic, APL would be the most readable language there is. Alas, it isn't. At best, it is as readable as any other language and my personal bias is simply a matter of experience (which does not include APL, hence I find it difficult to read). But I think that keywords are actually *better* readable than special characters. C like syntax is so familiar to us that we mistakenly consider it readable, which it really isn't.  
> **username_18** (2023-07-04): It is interesting that you say that keywords are more *readable*.  I don't necesarily disagree.  But when I look at code (whether it's C/C++ or Lisp) I don't actually *read* the delimiters.  I see them, but I don't read them.  They usually only consciously register if they look wrong.  Rather like punctuation in natural language text.  I find having keywords (especially different ones) for delimiters about as hard to read as natural language would be with the punctuation spelled out as words.  
> **username_19** (2023-07-04): @NielsHolst A... cleavage-delimited code block?  
> **username_20** (2023-07-04): @Peter-ReinstateMonica I'd say the point is not so much that keywords and identifiers should be as short as possible. Words contain information that _can_ be useful for readability, though there are limits... Cobol anyone? The actual point is that specifically the `EndFoo` the information contain only redundant information, and therefore add nothing that would really help readability but only noise.  
> **username_21** (2023-10-30): @NielsHolst: In PASCAL, `(.` and `.)` were digraph synonyms for `[` and `]`, and `(*` and `*)`  were synonyms for `{` and `}`.  
---
### Answer by username_22 on 2023-07-03. Score: 15
The reason most languages use `}` is C did it that way.
> **Comments:**
> **username_23** (2023-07-03): But why did C do it that way, and why did so many people consider it such a good idea that they used in their own programming languages?  
> **username_24** (2023-07-03): @Philipp C does it that way because B does it that way :-)  
> **username_8** (2023-07-03): @Philipp C was born in 1972. I assume that Kernighan & Ritchie would have used the same type of terminal that I used during the early 1970s, an [ASR35 teletype](https://www.blunham.com/Misc/ASR35/). If I have been offered a choice between two languages, which used _{...}_ and _begin...end_, I know which one I'd have gone for.  
> **username_22** (2023-07-04): @Philipp Why C did it that way is essentially irrelevant. C could have picked anything. The point is that C used it, and C was extremely popular and highly influential (for reasons unrelated to its syntax), so many modern languages are in some way descended from it, and many of them choose to use the same syntax.  
> **username_17** (2023-07-04): @Philipp If you use ink and paper via teletypes (or punch cards, or punched tape) to program, and if you count your mass storage in kB, every character counts. You strip off carriage returns, and you indicate blocks with single characters.  
> **username_25** (2023-07-20): But perhaps C being extremely popular and highly influential is not _totally_ unrelated to its syntax!  
> **username_22** (2023-07-20): @PabloH Perhaps. But we have no evidence for that given the overwhelming other factors that led to its widespread adoption.  
> **username_10** (2024-03-16): If you used punch cards, you didn't even have a } character.  Which is why the trigraphs were part of the language definition. The reason c had the } character was because they were using CRT serial terminals, not punch cards.  
> **username_21** (2024-09-09): @AlexisKing: C was developed in an era where on-line program editing was the normal way of entering code, which meant it was desirable to minimize the number of characters required to express a construct.  Earlier languages dated to a time where the amount of space occupied by a program was based upon the number of lines (about six lines per cubic inch), independent of the amount of content on those lines, so a line with `END WHILE` would take no more space than a line with `}`, but when doing on-line editing character count matters.  
> **username_26** (2024-09-10): @supercat, CRTs were even more space-constrained than punch-cards in terms of what you could view at once. I suspect the perceived advantages of braces included the speed of (and unambiguity for) parsing, the reduction in visual clutter and in-keeping with the generally greater use of symbols, and ability to consolidate the open and close onto a single line (together with the two or more statements inside the block, the minimum to justify an explicit block being used at all) without causing excessive line length.  
> **username_21** (2024-09-10): @Steve: CRTs would favor minimizing the number of lines (something C allowed, but FORTRAN didn't), but could fit a line full of content just as easily as a line containing nothing but a brace character.  Using a teletype (paper or glass), however, the time required to display a long line would be greater than that for a short line, whereas most FORTRAN-era printers would on average take longer to output a line containing a single brace than a line containing only uppercase alphanumerics.  
---
### Answer by username_6 on 2023-07-03. Score: 11
It is not used in most language because indentation makes the extra information in endX statements redundant noise.
In a bit of code that looks like this (please imagine that but ten times as long and twice as nested for the full effect):
if (██████) {
while(██████){
██████
██████
██████
// ██████
██████
}
for(██████; ██████; ██████) {
if (██████) ██████;
██████
██████
}}

Markers to indicate which end or } refers to what would be very useful but programmers don't write code like that. They indent their code to indicate what matches with what that and makes the additional information become redundant. Moreover, (as per @BoppreH's elegant demonstration in another answer) the additional text is more easily confused with the other syntactic markers and so actually makes the code harder to read.
Since indentation, whilst not mandatory in most languages, is expected behaviour of programmers these days - and has been for a long time now - any benefit of having individually tagged end markers is lost.
> **Comments:**
> **username_12** (2023-07-05): "Programmers don't write code like that"--unfortunately, some of them do. You should see some of the Java code I have to work with. :P  
---
### Answer by username_27 on 2023-07-03. Score: 5
As another answer says, labeling the end constract would be mostly redundant. It would only have semantic value if you allow ending multiple blocks with a single end, e.g.
IF ...
    WHILE ...
        body
ENDIF

In the above, ENDWHILE can be omitted because ENDIF implicitly closes all blocks contained in it.
The only language I can think of where this style is used is HTML. Some tags are automatically closed in some contexts (e.g. you can omit  before the next ). And HTML parsers will also auto-close some tags even when the language doesn't permit it, to implement the robustness principle.
In a language without distinct end tokens, you can always use a comment to help link the end to the beginning when you write large blocks. But blocks large enough to need this are also generally considered poor coding style. So we don't want to encourage it with language design that makes it easier.
---
### Answer by username_28 on 2024-09-09. Score: 3
I did want to point out that Turbo Pascal was no innovator when it came to `(*` and `*)` substituting for braces. Those digraphs are what I had to use when learning Pascal in 1979 on our Hollerith punched-card mainframe, which used EBCDIC internally, which doesn't even *have* the brace characters.

Languages that predate the ubiquity of ASCII would certainly be biased towards keywords rather than punctuation for blocking.

Languages developed on slow mechanical I/O devices (punched cards or ASR33 TTY's) would be biased towards shorter rather than longer sequences. They also would not want to care about indention, because re-punching a bunch of cards just because you added an IF in front of them would be a maddening waste of time and materials. Not to mention the risk of running into the maximum width of a punched card.

These early languages would then have set the stage for their descendants.
> **Comments:**
> **username_21** (2024-09-10): An interesting difference between FORTRAN-era printing devices and those of C's inventors is that the time required to output a line on the former would depend upon the "rarest" character on the chain (many chains would have alphanumerics repeated something like five times, but characters like braces only once), so the chain would have to make at most 1/5 of a revolution to print all of the alphanumerics on a line, but on average half a resolution to output even a single brace character.  
> **username_28** (2024-10-02): The TTY40 we used back in the day had two chains: uppercase-only and mixed case.  The UC chain had 5 (?) sets of characters on it, the ULC chain had 3.  The former printed listings noticeably faster than the latter, and since listings were all these printers were used for, the fleet was exclusively UC.  (I have a ULC chain on my personal TTY40 that I acquired many years ago.  I can't remember the last time I fired it up.  Laser printers ate chain printers' lunches when they came out.)  
---
### Answer by username_24 on 2023-07-03. Score: 2
The original ALGOL way was that where an explicit END was needed the next token- or at least sometimes the remainder of the card- was treated as a comment.
Hence from Burroughs B5500 ALGOL:
...
    END IF
  END IF % ANYTHING AFTER END IS IGNORED HERE.                                 %
END.     % END MUST BE FOLLOWED IMMEDIATELY BY . HERE ------------------------ %

Derivative languages either dropped provision for an unparsed comment (i.e. any comment had to be marked explicitly), or merged the commonly-used comments into the token (i.e. END IF became ENDIF).
Somewhat later I've realised that I've misread the question. I think OP intended to ask "why do most languages use END rather than ENDIF, ENDWHILE etc." but instead I focused on the ENDsomething aspect.
I'll leave my answer undeleted in the unlikely case that there's something of historical interest in it.
---
### Answer by username_26 on 2023-09-23. Score: 2
I think your language AEC is really quite interesting.
When it comes to programming languages, there are two main philosophies.
One is drawn from those who prefer natural language (invariably English), the other is drawn from those who prefer symbols. Each has its arguments and its areas of application.
It isn't found strictly necessary to have a special end token in block-structured languages, whether they be English-like or symbol-like. That's essentially how you get as far as Pascal with it's generic begin and end tokens.
In all languages, but especially in the English-style ones, there's a need to balance economy and clarity.
Research shows that people don't read letter-by-letter like computers process strings. When possible, they recognise whole shapes in a gestalt fashion - this applies generally, including applying to words, to sentences, and to blocks.
In English-like languages that have the potential to be almost infinitely verbose, keeping things as short as possible is still quite desirable, to avoid visual clutter and facilitate shape recognition.
So in principle, for those designing a programming language in a rational fashion, end is a perfectly good token. There isn't a need, at first, to justify why it isn't longer, because short is good.
However, experience shows that two situations are not uncommon. The first is to have several levels of blocks nested. The second is to have blocks longer than what can be shown on the screen. And both of these cases occur often enough together even.
Visual Basic (as an example of an English-like language I know well) further helps these situations in two ways. Firstly, it has special keywords to terminate a block which are different depending on the type of block. Secondly, with certain blocks (like For) where the same type of block is commonly nested, you can identify the block by the variable name.
For i = 1 To 5
    For j = 1 To 3
    ...
    Next j
Next i

I'm a regular user of SQL, and it's not uncommon nowadays for single statements (when consistently formatted) to run over several pages on screen, and for blocks to reach several levels deep when writing complicated procedures. Towards the end of a procedure, there is then a series of:
            end;
        end;
    end;
end;

In these cases, I miss VB's special block-ending keywords. And I agree that Pascal (and languages which follow it in this respect, like SQL) is deficient, and that repeating the block type at the end token is found to be a generally useful feature of a language, and it would be more desirable to have a syntax something like so instead:
            end if;
        end while;
    end if;
end procedure;
> **Comments:**
> **username_27** (2024-09-09): To make up for not having `end if` and `end while`, many programmers in C-style languages will put the starting keyword in a comment: `end /* if */;`  
> **username_26** (2024-09-09): @Barmar, yes I do so myself!  
---
