c语言 大括号

Okay, what the hell. In this story I will argue against one of the most popular syntax conventions by far in the programming world. Programmers love their curly braces. And few new programming languages dear break with this tradition firmly established with the C programming language.

噢 ，该死。 在这个故事中，我将反对迄今为止编程世界中最流行的语法约定之一。 程序员喜欢他们的花括号。 很少有新的编程语言可以与C编程语言牢固地建立的这种传统相抵触。

C gained massive popularity early and C++ piggy backed on this popularity. Then came Java which wanted to also piggy back on this success and thus adopted a similar syntax. The huge success of Java caused Microsoft to make their own Java clone, which later became C#. And over at Netscape they where making a LISP or Scheme language, meaning lots of parenthesis, but for marketing reasons it got a last minute remake and got curly braces too.

C很早就获得了广泛的普及，而C ++则支持这种普及。 然后出现了Java，Java也希望再次获得成功，因此采用了类似的语法。 Java的巨大成功使Microsoft制作了自己的Java克隆，后来成为C＃。 在Netscape上，他们制作LISP或Scheme语言，这意味着很多括号，但由于市场原因，它进行了最后一刻重制，并且也花了大括号。

Bottom line is that curly braces is a bit of an accident of history. I will here try to make the case that using keywords to denote scope like Pascal, Algol, Lua, Ada, Basic and Matlab to name a few examples is better.

底线是花括号是历史的偶然。 在这里，我将尝试使用关键字来表示范围，例如Pascal，Algol，Lua，Ada，Basic和Matlab来举例。

In many of these languages begin end marks a scope.

在许多语言中的begin end标记的范围。

Blocks and their indentation level is easier to identify because begin end is lager and more visible markers than { and }.

块及其缩进级别更易于识别，因为与{和}相比， begin end更大且可见的标记更多。

But this is not really the main issue. It is that braces must be able to make a case for why they are needed. Why? Because different forms of brackets and braces are of outmost importance in programming languages and we are in limited supply of them. We need them for the following:

但这并不是真正的主要问题。 括号必须能够说明为什么需要它们。 为什么？ 因为在编程语言中，不同形式的括号和花括号是最重要的，因此我们的供应有限。 我们需要它们用于以下目的：

Grouping arithmetic expression. Most use ( and ). (2 + x) * 4

分组算术表达式。 多数使用(和) 。 (2 + x) * 4

Grouping array elements and perform array access. Most use [ and ]. x = array[4]

对数组元素进行分组并执行数组访问。 多数使用[和] 。 x = array[4]

Specifying type parameter. vector<int> items.

指定类型参数。 vector<int> items.

In the latter case all the curly braces language have been forced to adopt < and > despite these brackets being a terrible choice. Why?

在后一种情况下，所有花括号语言都被迫采用<和>尽管这些括号是一个糟糕的选择。 为什么？

These symbols are already used in mathematical expression. In e.g. Julia this would be a no-go, because type parameters are specified as expressions in which the < and > operators are perfectly valid.

这些符号已在数学表达式中使用。 在例如Julia中，这是不可以的，因为将类型参数指定为其中<和>运算符完全有效的表达式。

The code below creates an empty array where the elements are of type Int.

下面的代码创建一个空数组，其中元素的类型为Int 。

xs = Vector{Int}()

The type parameter is inside curly braces. However in Julia it is perfectly valid to make the type parameter a more complex expression:

type参数在花括号内。 但是在Julia中，使类型形参成为更复杂的表达式是完全正确的：

ys = Vector{x > 0 ? Int : Float64}()

What we can see from this is that using < and > for the type parameter like C++ would fall flat on its face.

从中我们可以看到，对于像C ++这样的类型参数使用<和>会显得平淡无奇。

ys = Vector<x > 0 ? Int : Float64>() # BAD choice!

Try figuring out from the mess above where the type parameter begins and ends. My point with this example is that you can have many reasons to need braces for something in your language, thus we should not waste them where they are not needed.

尝试从上面的混乱中找出type参数的开始和结束位置。 我在本示例中的观点是，出于多种原因，您可能需要为您的语言中的某些东西使用括号，因此，我们不应在不需要它们的地方浪费它们。

Parenthesis are naturally a good fit for mathematics compared to begin and end.

与begin和end相比，括号自然很适合数学。

(3 + 2) * (4 - 2(2 + 1)) begin 3 + 2 end * begin 4 - 2 begin 2 + 1 end end

Yes nobody would want to use keywords for nested calculations. What about square brackets?

是的，没有人愿意使用关键字进行嵌套计算。 方括号呢？

xs[2 + ys[3]]xs begin 2 + ys begin 3 end end

Okay, I know, I am pointing out the bloody obvious. You really want your parenthesis in these cases.

好吧，我知道，我指出的是该死的明显。 在这些情况下，您确实需要括号。

However for scope we are in an entirely different situation. We almost never nest on the same line. Quite the contrary be almost alway prefer to mark the start and end of a scope on a separate line.

但是就范围而言，我们处于完全不同的情况。 我们几乎永远不会嵌套在同一条线上。 相反，几乎总是喜欢在单独的行上标记示波器的开始和结束。

Thus in your typical C and JavaScript code we end up lots of lines with only a single character. This is not prime real estate. We don’t need curly braces to cut down on typing. In fact they tend to waste typing.

因此，在典型的C和JavaScript代码中，我们仅以一个字符结尾很多行。 这不是主要房地产。 我们不需要花括号来减少打字。 实际上，它们往往浪费打字。

while i < 10 print(i) i += 1end

Let us compare the Julia code above to the C code below in terms of typing efficiency.

让我们在键入效率方面将上面的Julia代码与下面的C代码进行比较。

while (i < 10) { print(i); i += 1;}

Ironically the C example requires more typing on the keyboard. Let us tally up:

具有讽刺意味的是，C示例需要在键盘上进行更多键入。 让我们统计一下：

Each brace requires holding down a shift and a braces key. Since we have two braces that is 4 keys you need to touch. In Julia you only type end , as while also marks the beginning of the block. Julia wins with 1 keystroke.

每个大括号都需要按住Shift键和大括号键。 由于我们有两个大括号，即4个键，因此您需要触摸。 在Julia中，您只键入end ，因为while也标记了该块的开始。 Julia赢得1击键。

Each line needs a semicolon at the end. 2 keystrokes Julia doesn’t need.

每行的末尾都需要使用分号。 Julia不需要2次击键。

Expressions in if, for and while-statements need parenthesis. Each require holding down shift. 4 keystrokes Julia doesn’t need.

if ， for和while语句中的表达式需要括号。 每个都需要按住Shift键。 Julia不需要4个按键。

Thus we end up with 7 more keystrokes on the C solution. And does that gain us any clarity or clear benefit? I would say no.

因此，我们最终在C解决方案上还有7次击键。 这会给我们带来任何清晰或明显的好处吗？ 我会说不。

The space saving at the last line is of no value as there are no other characters there. In fact the single character makes the end of the code less visible.

最后一行节省的空间没有价值，因为那里没有其他字符。 实际上，单个字符使代码的结尾不那么可见。

回顾 (Recap)

Syntax choices have to have rational reasons for existing. Benefits must be weighed against downsides. The way modern software is written cannot demonstrate any advantages.

语法选择必须具有合理的理由。 必须权衡利弊。 现代软件的编写方式无法展示任何优势。

They don’t save keystrokes, nor do they save any precious screen real-estate as they typically have a whole line to occupy all by themselves.

他们不保存击键，也不保存任何珍贵的屏幕房地产，因为它们通常有整条线可以自己占据。

2. They don’t enhance clarity of code.

2.它们不会提高代码的清晰度。

However they to cause serious disadvantages. We have very limited number of braces to choose from, thus they must be rationed for the most important cases such as mathematical expressions, array and dictionary access. Finally a lot of modern languages have some form of type parameterized types. Julia is one example of this.

但是它们造成严重的不利。 花括号的数量非常有限，因此必须对最重要的情况(例如数学表达式，数组和字典访问)进行配给。 最后，许多现代语言都有某种形式的类型参数化类型。 Julia就是一个例子。

Using < and > is somewhat of a desperate measure, when you have run out of choices.

当您用尽所有选择时，使用<和>似乎是一种绝望的措施。

I know this is an unpopular opinion as many people are in love with C/C++ syntax. They want curly braces for scope and they want < > for parameterized types. Yet apart from familiarity do these choices offer any advantages? In my opinion they have a number of clear disadvantages which should carry more weight than familiarity.

我知道这是一个不受欢迎的观点，因为许多人都喜欢C / C ++语法。 他们希望使用花括号作为范围，并且希望使用< >作为参数化类型。 但是，除了熟悉之外，这些选择是否还具有任何优势？ 在我看来，它们有许多明显的弊端，这些弊端应比熟悉情况更重要。

After all we have large family of languages using the Pascal style block marking.

毕竟，我们拥有使用Pascal样式块标记的大量语言。

While I love feedback, keep in mind that this opinion of mine is no threat to your current most beloved curly braces programming language. Rather I hope to convince you to not think of language which don’t use curly braces as somehow being second rate and not worthy of your attention. In fact these langauges most likely made a more intelligent choice 😉.

尽管我喜欢反馈，但请记住，我的这种观点并不威胁您当前最钟爱的花括号编程语言。 相反，我希望说服您不要考虑不使用花括号的语言，因为它以某种方式是第二流的，不值得您注意。 实际上，这些语言很可能是一个更明智的选择。

翻译自: https://medium.com/@Jernfrost/the-case-against-curly-braces-languages-dd0a55840fcb

c语言 大括号

相关资源：微信小程序源码-合集6.rar