不知道大家有沒有這樣的經歷，當你來到一個新的公司或者是接手一個新的項目的時候，最怕的就是看前任的代碼（外加沒有文檔），最氣人的還是，連簡單的注釋都沒有多少，每當遇到這種情況都想把前任程序員拉出來斃了。

吐槽歸吐槽，誰的新歡不是誰的舊愛呢？自己寫完的項目可能也要交給后來人，那我們可能是想被斃掉的那一位了。我仔細想了想，可能一切的鍋都得歸于我們寫代碼時候的炫技。

程序語言都會提供這樣的或者那樣的特性，這些特性在某些時候可以幫助我們省些代碼或者在特定情況幫助我們減少失誤帶來的影響。我相信存在即合理，然而語言的有些特性并不是什么好東西，很多特性都經不起時間的考驗（代碼的不斷迭代），最后帶來的bug可能很難找到。

還有一點，我相信每個程序員都想要寫好代碼，或者認為短小精悍的代碼才算好。我們也會經常吹牛逼說：這個功能別人要寫100行，我不到一半行就搞定了。不是說不好，但是很多情況，利用語言里的一些特殊構造來縮減代碼可能會讓人難以理解。

也就是說：并不是語言提供什么特性，我們就一定要使用起來。實際上我們只需要其中很小的一部分功能，就能寫出優秀的代碼，實現特定的功能。

下面我根據一些經驗，針對一些有問題的語言特性，規范一些代碼，為什么這樣能讓代碼更簡單。

切記不要省略花括號

這個相信大家都有體會，也是經常會這么用的，比如：

if(condition1)
action1();

而不是

if(condition1){
action1();
}

這種情況最起碼可以省了一兩行代碼了，而且也還算是很好看。但是這樣也會經常引起一些意想不到的問題，比如，在后面想要多加一句話action2()到這個if里面，有可能會把代碼改成：

if(condition1)
action1();
action2();

這可不是python，當我們都有縮進的時候，潛意識里肯定是以為它們是在一起的，以為它們只會在if的條件為真的時候執行，然而action2()卻其實在if外面，它會被無條件的執行。

看似很簡單的問題，可能都很容易發現這個錯誤，但實際上卻容易被忽視。只要是if-else語句，把花括號全都打上，就可以不用擔心漏掉了，相當于沒這個特性，這樣就可以保持完全的一致性，減少不必要的思考。

if(condition1){
action1();
action2();
}

避免使用自增減表達式（i++，++i，i–，–i）

我們總喜歡騷操作，在我之前寫過的一篇文章中淺析C語言中一些“令人吃驚”的結構 ，表明C語言會同意一些"令人震驚"的結構，但實際上自增減操作表達式其實是歷史遺留的設計失誤。

像是c = a+++++b;這種類型的表達式含義比較蹊蹺，非常容易弄錯，混淆纏繞在一起，把語義搞得烏七八糟。

這種表達式的結果可能取決于求值順序，在某種編譯器下能正確運行，換一個編譯器就可能出現離奇的錯誤了，當然這個我并沒有驗證，但這種看起來太騷了。

如果你想寫function(i++)，你完全可以把它拆成

intt=i;
i+=1;
function(t);

這兩個表達式分解成兩步，如果想寫function(++i)，可以拆成

i+=1;
function(i);

拆開之后的代碼，含義完全一致，卻清晰很多。到底更新是在取值之前還是之后，一目了然。

當然我們也會有更細致的爭論，例如：i++或者++i的效率比拆開之后要高，當看到這種究根源的結論我其實是很感興趣的，但實際上這些代碼經過基本的編譯器優化之后，生成的機器代碼是完全沒有區別的。

而且自增減表達式只有在for循環的update部分、寫成單獨的一行這兩種情況下才可以安全的使用，這兩種情況是完全沒有歧義的。其余情況需要避免使用，比如用在復雜的表達式里面，比如function(i++)，function(++i)等等。

合理使用括號

使用括號可以確保表達式的優先級，而我們總是不大喜歡在表達式中添加括號，但是盲目依賴操作符優先級往往得不償失。

當然對于簡單的加減乘除我們可以使用，比如1+4*9，而不需要寫成1+(4*9)，然而在一些稍微復雜一點的表達式中我們可能不喜歡括號，比如1<<2+4*9。

當然，這也考研我們的基本功，但我相信移位操作<<的優先級，大部分人第一眼可能是不大熟悉的，所以這導致了我們再一次廢了多一點腦子或者Google了一下。

由于x << 1相當于把x乘以2，那么這個表達式可能會被誤以為(1<<2)+(4*9)，然而實際上<<的優先級比加法+還要低，所以這表達式其實相當于1<<(2+4*9)

解決這個問題的辦法，不是要求每個人都去把操作符優先級表給硬背下來，而是合理的加入括號。雖然沒有括號也表示同樣的意思，但是加上括號就更加清晰了，是不是呢？

總結

再次聲明，這里只是舉了幾個簡單的例子，所謂存在即合理，特性既然存在肯定是在某種特定情況下有用武之地的，這一點我們毋庸置疑。

但實際到我們自己敲的代碼，或者在工程應用中，為了避免花過多的時間與精力放在這種費眼睛、費腦子的事情上，是適得其反的。

我們需要寫簡單的代碼，需要看簡單的代碼，需要沒有歧義與爭論的代碼，這才是我們的終極目標，希望本文所闡述的思想對大家有用處。