雖 然這樣的文章非常的多,，并且，就算是對于編程新手來說,，也是非常的簡單和顯而見,，但是,，在我們進(jìn)行Code Review過程中，我們還是能夠看到那些非?；靵y的代碼,，所以，有些時候,，你會在想,，是不是這樣的規(guī)則太多了，導(dǎo)致我們的程序員記不住,。雖然我們在以前 的文章中一遍又一遍的說過（比如：《優(yōu)質(zhì)代碼的十誡》）,，千言萬語總結(jié)一下,，無論你用什么樣的語言,，最最基本的編程原則就是下面這四條。

1 – 簡短的方法

簡單才會易讀,，簡單才會容易,，簡單才能重用，簡單才能保證質(zhì)量,。把一件事搞復(fù)雜,，是一件簡單的事；而把一件事變簡單,，這則是一件復(fù)雜的事,。 KISS-Keep it Simple Stupid是一種哲學(xué)，Do one thing, Do it best也是一種哲學(xué),。這些都是在告訴我們,，做設(shè)計，做產(chǎn)品,，不要把所有的東西一下子都考慮進(jìn)來,，否則將會讓你的事情變成一團(tuán)糟，剪不斷理還亂,，就是這樣 道理,。把復(fù)雜的事情，困難的事情,，逐步細(xì)化,，分解成一個一個簡單而單一的事情，然后再把他們拼裝起來完成一個復(fù)雜的事情,，是我們?nèi)绾瓮瓿梢粋€巨大并復(fù)雜的 項目的通用方法,。

編程也是這個道理，維護(hù)代碼的成本會比你創(chuàng)造代碼的成本要大得多,，所以,，一個簡短的方法不但可以有利于閱讀,，維護(hù)，重用,，同樣在進(jìn)行排錯調(diào)試測試的 時候也能起到巨大的幫助,。比如，對于一個簡單的方法或函數(shù),，單元測試,，功能測試，性能測試,、代碼覆蓋,，質(zhì)量保證都能變得相當(dāng)簡單，而這些眾多的質(zhì)量優(yōu)良的 方法最終組成了那質(zhì)量過硬的最終產(chǎn)品,，并讓我們在以后的代碼不斷改進(jìn)中繼續(xù)充當(dāng)重要的作用,。

2 – 選擇望文知意的直觀的變量名和函數(shù)名

無論是變量名還是方法名，都不能太長或是太短,。一個好的命名,，應(yīng)該是“自解釋的”，直觀的,，望文知意的,。通常來說，一個好的命名應(yīng)該是知道這個變量 /方法要干什么事情,，比如GetComputerName(),，isAdmin等等，對于變量名來說,，通過其名字,，我們可以知道這個變量的類型（整型，浮 點(diǎn),，指針,，……），種類（全局,，成員,，局部，靜態(tài),，……）,。關(guān)于命名的事情，可以查看《編程命名中的7+1個提示》和《編程中的命名設(shè)計那點(diǎn)事》查看更多的內(nèi)容,。

3 – 只寫有意義的注釋

代碼寫得好的話,，是不需要注釋的。與其花費(fèi)大量的時候去寫注釋,，還不如把這些時間花在代碼重構(gòu)上,，簡潔/易讀的代碼比詳細(xì)的注釋更有意義,。另外，如 果你需要使用你的注釋來生成文檔,，那么也不需要太過復(fù)雜,，這通常用來做API的文檔，這個時候,，關(guān)鍵不在于你是如何實現(xiàn)的,，而是在于告訴別人完成什么樣的 事并如何使用之?？傊?，一句話，如果你的代碼足夠的簡單和清楚,，你是不需要寫注釋的,。
4 – 讓你的代碼可讀

你的代碼并不只是讓編譯器去閱讀的，你的代碼更應(yīng)該是讓你的同事和其它人閱讀的,。所以,，一定要遵守團(tuán)隊內(nèi)部的那些最中規(guī)中矩的編程規(guī)范或代碼風(fēng)格， 千萬不要在代碼中使你的小聰明或是偷懶或是hack代碼,，那樣做的結(jié)果只會有兩個，一個是你的代碼會被后人罵得一無是處,，另一個就是當(dāng)你在以后維護(hù)你的代 碼時無異于搬起石頭砸了自己的腳,。編碼堅持最基本的兩個原則—— KISS 和DRY，剩下的就是順從于自然,。