不知道此類文章是否合適發在首頁，如果不合適，請管理團隊告知，我將馬上撤走，不過週末人很少，明天一到肯定是發帖高峰期，我的這篇也會馬上被淹沒，應該沒有什麼大問題。
正文：眾所周之，c#是乙個含有豐富的語法糖的語言，每次c#推出一些新的特性的時候，很多開發者都丟下這句話：不過是個syntax sugar而已。一邊我們為c#為我們帶來很多簡潔的語法，「優雅「的程式設計風格而高興不已，一邊我們又在」鄙視「這種只在其表而沒有內涵的做法。
這裡很想和引起大家一番對語法糖的討論。
首先還是關注一下syntax sugar的歷史吧，俗話說要了解乙個東西還是先知其歷史。
我們從google開始：
在wiki裡我找到了關於語法糖的一些歷史介紹，語法糖(syntactic sugar
),是由peter j. landin(和圖靈一樣的天才人物，是他最先發現了lambda演算，由此而創立了函式式程式設計)創造的乙個詞語，它意指那些沒有給計算機語言新增新功能，而只是對人類來說更「甜蜜「的語法。語法糖往往給程式設計師提供了更實用的編碼方式，有益於更好的編碼風格，更易讀。不過其並沒有給語言新增什麼新東西。
從wiki的介紹上來看，好像這個語法糖還是乙個好東西。wiki上還舉了乙個例子：在c語言裡用a[i]表示*(a+i),用a[i][j]表示*(*(a+i)+j)，看來語法糖不是「現代語言「才有啊，連我們的老大哥c也有，而且這種寫法簡潔明瞭，也更好懂了。
wiki裡還提到，實際上從面向過程到物件導向也是一種語法糖啊，c語言可以通過它的指標、型別轉換，結構實現物件導向的程式設計風格，但是c++更進一步的推廣了這種風格，更好用了，不過到了c#把oo的風格發揮得淋漓盡致。oo的程式設計風格對於面向過程來說是不是一種語法糖呢？如果按照wiki的理解，只有計算機硬體指令才不算語法糖，而其他一切利用編譯器、彙編器將**抽象，和自然語言更相近的手段都算語法糖。
現在很多很多程式設計思想，程式設計理論層出不窮，當然，對於學習來說我們是要抓住技術的核心，但對於工程來說如何提高工程質量，如何提高工程效率也是我們要關注的，既然這些語法糖能輔助我們以更好的方式編寫**為什麼要「抵制「呢?
我想語法糖和其他程式設計思想一樣重要，什麼duck type，人本介面，最小介面，約定優於配置，其實不都是一些思想上的「語法糖「？
不過也並不是沒有反對的聲音，這其中就有圖靈獎的第乙個獲得者: alan perlis。
.net從2.0到3.0到3.5底層clr並沒有做更新，沒有新增任何新的il指令，所以c#從2.0到3.0中所有的特性都是語法糖，就算從1.0到2.0，也只有乙個泛型不是語法糖，其餘的新特性也都是如此，但是每一次c#發布新特性的時候我們不得不為之而鼓舞，為之而喝彩。新的語法可以釀造更好的程式設計風格，以前一些難以實現的方面現在也輕而易舉了。
ps：在蒐集有關語法糖的資料的時候還蒐集到乙個以前不了解的名詞：syntactic salt(難道叫做」語法鹽」?)。它的意思和語法糖相反，它促使程式設計師難以書寫壞**。
python 語法糖太多 python 語法糖
匿名函式 lamda表示式 def add x,y return x y 等價於f lamda x,y x y f 1,2 三元表示式 wefx 1 y 2 c x if x map對映關係 def square x return x x list x 1,3,10 list r map squar...
關於語法糖
語法糖 syntactic sugar 也譯為糖衣語法，是由英國計算機科學家彼得 約翰 蘭達 peter j.landin 發明的乙個術語，指計算機語言中新增的某種語法，這種語法對語言的功能並沒有影響，但是更方便程式設計師使用。通常來說使用語法糖能夠增加程式的可讀性，從而減少程式 出錯的機會。eff...
Python中語法糖及帶參語法糖
在python中，符號常被稱作語法糖 裝飾器 在某函式定義時，用以包裝該函式，以達到擷取，控制該函式的目的。def d f print d.k f 此處保留了傳進來的原函式 f def f x return k x 2 return f 此處不能寫成f x f是函式控制代碼，如果帶 則呼叫，這裡只返...