各位猿类们如何看待语法糖？

[jtn007]

语法糖很多时候的确能让代码看起来，写起来更加舒服，但是有时却会降低一些程序的运行效率。这个社区里大多都不是C,C++这种底层的更多追求运行速度的猿们吧？不知道大家怎么看？

[Keyes]

C/CPP/ASM一样可以写出高效率又好看的语法的吧，这个不存在，数学算法的代码在我看来再好看也不好看……

现在和同事协作主攻Python，可读性还是放在第一位，至于效率嘛……不违反大原则（比如存储、IO资源滥用等）的情况下，语言效率可以放在最后一位，卡住程序的永远是IO而不是语言效率

[jtn007]

@Keyes 我感觉是不是在硬件不断快速升级的时代，除了实时性特别强的一些代码，是不是都是可读性和敏捷开发大行其道？

[2thetop]

语法姓糖，甜到哀伤。

[seeker]

我理解语法糖的目的与高级语言的目的差不多，让代码写起来方便简介易懂。

[ceclinux]

原来还有一种东西叫语法糖，有种东西叫语法盐

[angelface]

C里的a[i]和i[a]应该也是个语法糖吧，c[][]应该也是，我觉得和速度没什么关系。

[9hills]

我怎么觉得 语法糖 一般是降低了程序的可读性来换取效率啊，不管是写程序的效率还是程序运行的效率

[Keyes]

@jtn007 什么是敏捷开发我不懂……协作的话在我这边可读性肯定是放在第一位，无论任何语言。当然这也不是一棒子打死的，还要看小团队的默契程度，几个人水平相当，写代码的方式和想法都差不多，就算不考虑什么语法糖也能看得懂想得到，那就可以用一些技巧或高级特性简化代码

比如，我团队里的同事PYTHON水平都差不多，达到了了解PYTHON大部分特性的程度，我要实现一个取100以内可以被2整除的自然数列表：

>>> s_list = filter(lambda x:not x%2, xrange(0, 100))
>>> print s_list
一行就搞定了

反之，如果团队里有刚刚了解编程的，为了尽量能让他读懂，我会这样写：
>>> s_list = []
>>> for i in range(0, 100):
>>> if i % 2 == 0:
>>> s_list.append(i)
>>> print s_list

这样不高级特性，不用说xrange和range有什么区别，不用说lambda和filter是什么东西，随便有点编程基础的人都可以大致猜到这段代码的功能

要说这两种方式有多大的语言效率影响？我想实际应用中如果不是大量频繁使用是可以忽略的

不知道我举例的意思能不能说清楚我想表达的，大概就是说，要不要考虑语法，还是要看与你协作人的各项特征（当然别人也会迁就你，如果他考虑到这点的话）

[zhujinliang]

如果是我了解原理的语法糖，当然该用就用了，没有把握的不会用。
我印象中没有说哪个语法糖会牺牲效率，语法糖只是代码替换，按理说你不用语法糖一样需要通过相同的过程来实现。

C语言上都会用#define造一个语法糖，如果算的话。。。

[aisk]

@Keyes 花一下午时间把lambda和filter搞懂不是更好吗？

[ispinfx]

@Keyes 花一下午时间把lambda和filter搞懂不是更好吗？

-----------------------------------------------
+1

[seeker]

效率跟语法糖的实现有关系。大部分语法糖不会影响效率，特别是编译型语言，语法糖在编译器就转化掉了，运行时根本不知道你是是否使用了语法糖。

[FrankFang128]

性能恐惧症，得治。

[jtn007]

@FrankFang128 哈哈，其实我倒还好，主要是我和小伙伴们讨论一道题时有感而发，我是提倡代码简洁优雅的，小伙伴给我提O(n)~~

[Keyes]

@aisk
@ispinfx

别人学习，是要给别人时间的，每个人的性格、学习方式不一样也会造成差距。而且我这更倾向于需求导向，先想怎么解决需求、理清业务流程，然后尝试做DEMO，再说你往后能怎么优化提高，语言特性有时候显得并不是那么重要，团队大家都是绑在一起的

PS：一点拙见，并非绝对……

[sandtears]

囧... 我不喜欢语法糖，因为会降低可读性... 我有强迫症，写代码尽量带注释

[viator42]

有就尽量用,既然出现了这种写法肯定和这种语言的特性有关,像a[][]已经是约定俗成的了不用反而很奇怪.
python的for in语句和java的iterator迭代器应该也算语法糖

[tioover]

a.__add__(b)

[nil]

语法糖和性能应该没什么关系吧，语言的性能应该考虑虚拟机VS原生，虚拟机性能，静态类型VS动态类型，面向对象语义是发送消息还是函数调用神马的~

至于编码的话，感觉还是语法单位越少越好吧，map reduce之类的应该是支持第一类函数的结果，随便学学，代码易读性的提升不是一点半点啊~ 不支持第一类函数的语言没法做这种抽象，应该可以认为比较弱吧~

[darasion]

知道有这么回事，然后选一种最通用的，一直用下去。