Two of the major influences to C were the Algol family of languages (Algol 60 and Algol 68) and BCPL (from which C takes its name).
BCPL was the first curly bracket programming language, and the curly
brackets survived the syntactical changes and have become a common
means of denoting program source code statements. In practice, on
limited keyboards of the day, source programs often used the sequences
$( and $) in place of the symbols { and }. The single-line '//'
comments of BCPL, which were not taken up in C, reappeared in C++, and
later in C99.
From http://www.princeton.edu/~achaney/tmve/wiki100k/docs/BCPL.html
BCPL introduced and implemented several innovations which became quite
common elements in the design of later languages. Thus, it was the
first curly bracket programming language (one using { } as block
delimiters), and it was the first language to use // to mark inline
comments.
From http://progopedia.com/language/bcpl/
Within BCPL, one often sees curly braces, but not always. This was a limitation of the keyboards at the time. The characters $( and $) were lexicographically equivalent to { and }. Digraphs and trigraphs were maintained in C (though a different set for curly brace replacement - ??< and ??>).
The use of curly braces was further refined in B (which preceded C).
From Users' Reference to B by Ken Thompson:
/* The following function will print a non-negative number, n, to
the base b, where 2<=b<=10, This routine uses the fact that
in the ASCII character set, the digits 0 to 9 have sequential
code values. */
printn(n,b) {
extern putchar;
auto a;
if(a=n/b) /* assignment, not test for equality */
printn(a, b); /* recursive */
putchar(n%b + '0');
}
There are indications that curly braces were used as short hand for begin and end within Algol.
I remember that you also included them in the 256-character card code
that you published in CACM, because I found it interesting that you
proposed that they could be used in place of the Algol 'begin' and
'end' keywords, which is exactly how they were later used in the C
language.
From http://www.bobbemer.com/BRACES.HTM
The use of square brackets (as a suggested replacement in the question) goes back even further. As mentioned, the Algol family influenced C. Within Algol 60 and 68 (C was written in 1972 and BCPL in 1966), the square bracket was used to designate an index into an array or matrix.
BEGIN
FILE F(KIND=REMOTE);
EBCDIC ARRAY E[0:11];
REPLACE E BY "HELLO WORLD!";
WRITE(F, *, E);
END.
As programmers were already familiar with square brackets for arrays in Algol and BCPL, and curly braces for blocks in BCPL, there was little need or desire to change this when making another language.
The updated question includes an addendum of productivity for curly brace usage and mentions python. There are some other resources that do this study though the answer boils down to "Its anecdotal, and what you are used to is what you are most productive with." Because of the widely varying skills in programming and familiarity with different languages, these become difficult to account for.
See also: Stack Overflow Are there statistical studies that indicates that Python is “more productive”?
Much of the gains would be dependent on the IDE (or lack of) that is used. In vi based editors, putting the cursor over one matching open/close and pressing % will then move the cursor to the other matching character. This is very efficient with C based languages back in the old days - less so now.
A better comparison would be between {} and begin/end which was the options of the day (horizontal space was precious). Many Wirth languages were based on a begin and end style (Algol (mentioned above), pascal (many are familiar with), and the Modula family).
I have difficulty finding any that isolate this specific language feature - at best I can do is show that the curly brace languages are much more popular than begin end languages and it is a common construct. As mentioned in Bob Bemer link above, the curly brace was used to make it easier to program as shorthand.
From Why Pascal is Not My Favorite Programming Language
C and Ratfor programmers find 'begin' and 'end' bulky compared to { and }.
Which is about all that can be said - its familiarity and preference.
The brace at the end of the line is the ancient K&R C standard, from Brian Kernighan and Dennis Ritchie's book The C Programming Language, which they published in 1978 after co-inventing the UNIX operating system and the C programming language (C was mostly designed by Ritchie, based on B, which another Bell employee Ken Thompson had adapted from the older BCPL programming language), at AT&T.
There used to be flame wars about "the one true brace style."
So Ritchie created the C language, and Kernighan wrote the first tutorial, when computer displays only showed a few lines of text. In fact, UNICS (later UNIX) development started on a DEC PDP-7, which used a typewriter, printer and paper tape for a user interface. UNIX and C were finished on the PDP-11, with 24-line text terminals. So vertical space was indeed at a premium. We all have slightly better displays and higher resolution printers today, right? I mean, I don't know about you, but I have three 24" 1080p displays in front of me right now. :-)
Also, so much of that little book The C Programming Language is code samples that putting the braces at the ends of the lines instead of on their own lines allegedly saved an appreciable amount of money on printing.
What is truly important is consistency throughout a project, or at least within a given source code file.
There are also scientific studies showing that the brace on its own line (indented to the same level as the code, in fact) improves code comprehension despite what people think they think of the aesthetics. It makes it very clear to the reader, visually and instinctively, which code runs in which context.
if( true )
{
// do some stuff
}
C# has always supported evaluating a single command after a branching expression, by the way. In fact, that's the only thing it does, even now. Putting code in braces after a branching expression just makes that one command a goto (the compiler creates scope using jmp instructions). C++, Java, C# and JavaScript are all more or less based on C, with the same underlying parsing rules, for the most part. So in that sense, C# is not "based on Java."
Summing up, this is a bit of a religious/flame-war issue. But there are studies making it pretty clear that arranging code in blocks improves human comprehension. The compiler couldn't care less. But this is also related to the reason why I never put a line of code after a branch without braces--it's just too easy for me or another programmer to slap another line of code in there later and slip on the fact that it will not execute in the same context with the line right before or after it.
EDIT: Just go look at the Apple goto fail bug for a perfect example of this exact issue, which had very serious real world consequences.
if( true )
doSomething();
becomes...
if( true )
doSomething();
doSomethingElse();
In this case, doSomethingElse() executes every time, regardless of the outcome of the test, but because it is indented to the same level as the doSomething() statement, it's easy to miss. This isn't really arguable; studies back this up. This is a big source of bugs introduced into source code during maintenance.
Still, I'll admit that JavaScript closure syntax looks a little silly with braces on their own lines...aesthetically. :-)
Best Answer
Whenever something is in square brackets the content gets evaluated. Probably the reference was wrong because
<a [routerLink]="/user/bob">won't work because the code/user/bobhas syntax error, actually it's a malformed Regex.I checked the reference, now it has
<a [routerLink]="['/user/bob']">and<a routerLink="/user/bob">, both of them are correct.