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

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

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

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

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

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

切記不要省略花括號(hào)

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

if(condition1)
action1();

而不是

if(condition1){
action1();
}

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

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

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

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

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

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

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

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

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

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

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

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

i+=1;
function(i);

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

當(dāng)然我們也會(huì)有更細(xì)致的爭(zhēng)論，例如：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)等等。

合理使用括號(hào)

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

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

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

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

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

總結(jié)

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

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

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