为什么Syntactic Sugar有时被认为是坏事？

句法糖,恕我直言,通常使程序比从极简主义的原语集编码更易读,更容易理解.我并没有真正看到好的,经过深思熟虑的语法糖的缺点.为什么有些人基本上认为语法糖最多是多余的,最糟糕的是要避免什么？

编辑:我不想命名,但是因为人们问,似乎大多数C++和Java程序员,坦率地说,他们并不关心他们的语言完全没有语法糖.在很多情况下,他们不一定非常喜欢这种语言的其他部分足以使缺糖值得权衡,这是因为他们真的不在乎.此外,Lisp程序员似乎对他们语言的奇怪符号感到骄傲(我不会将其称为语法,因为它在技术上并非如此),尽管在这种情况下,它更容易理解,因为它允许Lisp的元编程工具像它们一样强大.

1> 小智..：

---

句法糖导致分号癌症.Alan Perlis

如果推理发生在没有参考上下文的情况下,很难推理出语法糖.有很多关于为什么"语法糖"好或坏的例子,如果没有语境,所有这些都没有意义.

你提到语法糖是好的,它使程序可读并且更容易理解......我可以反驳说,有时候,句法糖可以影响语言的正式结构,特别是当语法糖是设计期间的后期附录时编程语言

我没有考虑语法糖,而是想用精心设计的语言来提高可读性和易于理解,以及设计不良的语言.

问候,

---

有人可以解释Alan Perils的引用吗？我从来不明白.

---

@day这里有两个解释:1.http://softwareengineering.stackexchange.com/questions/194007/what-is-the-difference-between-syntax-and-syntactic-sugar#194020 2. https:// github. COM/strint/sicpAns /问题/ 2

2> ShuggyCoUk..：

---

在某些情况下,句法糖可以以令人不愉快的方式相互作用.

一些具体的例子:

第一个是c#(或java)特定的,自动装箱和锁/同步构造

private int i;
private object o = new object();

private void SomethingNeedingLocking(bool b)
{
    object lk = b ? i : o;
    lock (lk) { /* do something */ }
}

在这个例子中,有用的锁构造可以使用任何对象作为同步点,结合自动装箱,导致可能的错误.锁定只是每次都在i的新盒装实例上进行.有争议的是,锁定构造过度有用,并且锁定的其他一些特定构造会更好,但肯定组合仍然存在缺陷.

多个变量声明和指针:

long* first, second;

一个经典的错误(虽然容易发现).多个变量的糖不适合指针声明.

一些构造不需要糖的其他方面来引起问题,典型的例子是++运算符.它巧妙地让你避免写作

i = i + 1;

一个广泛使用的构造(以及一个本身具有bug的范围的构造,因为如果你想改变使用i,你必须记住更新这两个变量).但是,由于这很容易嵌入到其他表达式中,因此前缀和后缀的问题一直存在.在for循环中使用时无关紧要,评估发生在任何其他评估之外,但在其他地方使用它可能会引起混淆(因为您可能嵌入了计算的一个非常重要的方面(无论是当前还是下一个)价值应该用于一个非常小而容易错过的形式.

以上所有(除了编译器真正应该为你找到的锁/盒之外)是使用情况可能正常的情况,或者有经验的程序员可能认为"这对我来说非常清楚",但存在混淆的范围,当然对于新手程序员或那些转向不同语法的程序员.

---

公平点,无论如何,C的糖用于组装j/k;)

3> BobbyShaftoe..：

---

太多不必要的糖只会增加语言膨胀.我会说出名字,但之后我就会被焚烧.:)此外,有时语言使用语法糖而不是真正的实现.例如,有一种语言应该保持无名,其"泛型实现"只是一层薄薄的语法糖.

---

你在同一个响应中讨厌.NET和Java吗？好样的!;-)

4> Johan Kotlin..：

---

废话.C和Lisp程序员一直使用语法糖.

例子:

a[i] 代替 *(a+i)

'(1 2 3) 代替 (quote 1 2 3)