優雅的代碼總是讓人賞心悅目，比如下面有兩段代碼，都是實現了相同的功能，當你看完代碼A再來看代碼B時，你是否也有一種身心愉暢的感覺呢。
代碼A：
1 //如果用戶輸入的是偶數，就直接輸出，否則就+1之后再輸出。 2 int a; 3 printf("請輸入一個數字："); 4 fflush(stdin); 5 scanf("%d", &a); 6 7 //判斷情況再輸出 8 if (a % 2 == 0) 9 { 10 printf("結果是：%d\n", a); 11 } 12 else 13 { 14 a = a + 1; 15 printf("結果是：%d\n", a); 16 }
代碼B：
1 //如果用戶輸入的是偶數，就直接輸出，否則就+1之后再輸出。 2 int a; 3 printf("請輸入一個數字："); 4 fflush(stdin); 5 scanf("%d", &a); 6 7 //輸出結果 8 printf("結果是：%d\n", a + a % 2);
讓9行代碼變成1行代碼，卻依然能實現相同的功能，有着四兩撥千斤的味道，優雅感也就這么產生了。
然而，是否代碼越少就越優雅呢？大部分情況下是的，但並不絕對，盲目的追求往往適得其反，最顯而意見的例子就是下面這段代碼。
1 //請問以下代碼會輸出什么結果 2 int a = 0; 3 int i = 2; 4 a = (++i) + (++i) + (++i); 5 printf("%d\n", a);
其實今天主要就是想聊聊上面這段代碼，不少企業的面試題中就經常會出現類似這樣子的題目，我個人認為在面試題中出現這種題目的企業他們有着一個不負責任、不作為的人事部或者技術部。
為什么要考這種題目，我認為有三個原因：
1.在我們公司，這種代碼被認為是優雅的、高效的代碼，公司現有的程序中編寫了此類代碼，我們要求新加入的成員能閱讀這種代碼，甚至是在將來加入公司后，新成員也能寫出這種代碼。
2.在我們公司，我們認為這種濃縮代碼是晦澀難懂的，所以並不優雅，或者說是偽優雅。雖然我們並不會在實際的項目中編寫此類代碼，也不會要求新員工在加入公司之后來編寫此類代碼，但我們依然將它加入到面試題中，因為我們希望新員工是一名技能好手，爛熟於胸的掌握操作符的優先順序或許能一定程度上的說明部分問題。
3.在我們公司，面試題都是下載來的，或者歷史遺留下來的，那種題目看起來就很高大上，可以顯得我們公司也高大上，就留着吧。
遺憾的是，大部分企業是第三個原因吧。
代碼變少，卻依然能實現相同功能，自然是很棒。但真的依然能實現相同功能嗎？經過試驗發現，上面的這段代碼，在不同的編譯器下得到的結果是不同的。
l 在VS2010中新建VC++控制台項目，運行的結果為：15
先讓三個++i執行，i就變成了5，然后5+5+5=15
l 在VC++6.0中新建Win32控制台項目，運行的結果為：13
為什么結果是13，我也沒理解，求大神科普
l 在VS2010中新建C#控制台項目，運行的結果為：12
先++i就得到3，再++i就得到4，再++i就得到5
然后3+4+5=12
在VC++6.0的時代，出現這種面試題，無可厚非。但時代在變化，當今還考(++i)+(++i)+(++i)就顯得不太合適了，因為在不同的編譯器下，將會得到不同的結果。
如果是因為第2個原因，想找技能好手而將此類題目加入面試題中，那這得是一個多么好的好手，才能准確的回答出此題呢？我想標准答案應該是這樣的：“此題在VC++6.0中輸出13；在VS2010中用C++輸出15；用C#輸出：12；”，然后再附上各種結果的計算過程。我想這種好手應該很少，如果真在面試題中加入這個題目，企業不但找不到頂尖好手，反而會錯過很多一般般、還可以的好手。
如果是因為第1個原因，想找到能寫出優雅代碼的小伙伴，那就更加不靠譜了，因為首先，這種代碼並不是優雅的，因為它根本沒有“實現相同功能”，在不同編譯器下結果是不同的。
結論：將代碼濃縮的更少，卻依然能實現相同的功能，大部分情況下這是優雅的做法，但要考慮兩點，一是不能讓代碼變得特別晦澀難懂，二是要避免在不同編譯器下出現不同的結果。
PS：或許有些偏題了，水平有限，不吝賜教。