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

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

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

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

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

下面我根據(jù)一些經(jīng)驗(yàn)，針對一些有問題的語言特性，規(guī)范一些代碼，為什么這樣能讓代碼更簡單。

切記不要省略花括號

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

if(condition1)
action1();

而不是

if(condition1){
action1();
}

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

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

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

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

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

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

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

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

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

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

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

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

i+=1;
function(i);

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

當(dāng)然我們也會有更細(xì)致的爭論，例如：i++或者++i的效率比拆開之后要高，當(dāng)看到這種究根源的結(jié)論我其實(shí)是很感興趣的，但實(shí)際上這些代碼經(jīng)過基本的編譯器優(yōu)化之后，生成的機(jī)器代碼是完全沒有區(qū)別的。

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

合理使用括號

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

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

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

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

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

總結(jié)

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

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

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