代碼規范、如何寫出好代碼

作為一個程序員，肯定希望能寫出一手好代碼，看起來賞心悅目，又易於理解。既方便日后自己回來翻閱一眼就能明白代碼在干什么，又能讓接手的人很快上手，看到精妙的地方，不由自主地發出由衷的感嘆，悄無聲息地改變別人不好的習慣。

如何才能寫出好代碼呢？
在一次講座上，我聽了一位編程大神的看法，在這里分享給大家。

好的代碼應該至少具備下面這6個特點：

1. 使用空行來分割邏輯
2. 使用注釋和花括號
3. 不用的代碼和引用刪除
4. 不要用中文拼音做變量名
5. 可用，清晰優雅，高效
6. 多寫代碼，多思考

使用空行來分割邏輯

一般代碼超過30行左右，我們就在考慮，要不要把這些代碼封裝到一個方法中去。但是即使把這一大段代碼扔到一個方法中去，在主函數里調用這個方法，也不能保證以后不會修改這個方法了。所以為了自己和他人，還是有必要對比較長的代碼做一些處理。

一般即使是一個方法里面的代碼，邏輯也是可以分成一小塊一小塊的，這個時候我們在這些邏輯中間加上空行，就能告訴別人，我這個代碼這里，兩個空行中間的代碼關聯比較大。
在沒有添加任何注釋的情況下，因為有空行來分割邏輯，倒也不是一步就嚇退想要看你代碼的人。

使用注釋和花括號

在軟件開發的生命周期中，文檔應該是一直伴隨着的。這樣，后面接手的人看文檔就知道當時發生了什么。如果項目組有使用文檔來規范開發，那就要去遵守這個規定。但是文檔也有一個問題，就是代碼修改之后就要去修改文檔，萬一文檔沒有更新，接手的人反而會受到誤導。

文檔是個好習慣，在堅持更新項目文檔的同時，還要記得更新代碼的注釋，敲完代碼后隨手加上的簡短的幾個字，會提高看代碼的效率好多倍。

當你焦頭爛額的猜測原來編碼的人是怎么想的時候，看到添加了注釋的代碼，是不是有一種謝天謝地的感覺。

花括號{}在代碼中一般是有兩種形式：

• 一種是Visual Studio中C++源碼編輯器默認的上下對齊式

int main()
{
    cout<<"我是C++"<<endl;
}

• 一種是Eclipse中Java源碼編輯器默認的左花括號末尾排放式

public class HelloWorld { 
    public static void main(String args[]) { 
        System.out.println("我是Java"); 
    } 
}

C++默認方式，更容易看清代碼層次；Java默認方式減少占用的行數。

個人更加傾向於上下對齊式。但是個人意見需要服從團隊約定。你所在的團隊使用哪種方式，你就要使用哪種方式，和大家保持統一。

並且這兩種默認方式在集成開發環境IDE中都是可以調節的。比如Java的代碼，我平時這樣排版。

public class HelloWorld
{
    public static void main(String args[])
    {
        System.out.println("我是Java");
    }
}

不用的代碼和引用刪除

我們寫代碼時，需要修改代碼時經常注釋之前的代碼，然后把自己的代碼加上去。但是又不確定自己的代碼100%正確，不敢刪掉注釋的代碼，因為可能還會換為原來的代碼。

這樣導致的后果是以后如果沒有看出注釋代碼的問題，反而覺得很有道理的話，真的會將你的代碼重新用注釋代碼換回來。

我們寫代碼要相信自己，該刪的時候就要刪掉。要學會使用SVN或者是Git來進行版本控制。即使當前版本刪掉了，回滾到之前版本依然能夠找回來。大可不必擔心真的會刪掉了，這樣萬一有什么變故，也還是能夠找回來的。

我們也會經常注意到編輯器行首有很多黃色的感嘆號warning提示。雖然不影響程序正常運行，但是看着就是有點不雅觀，而且過多沒有使用的引用，或者外部包，框架，庫等等也會拖慢程序的運行速度。干掉這些無用的東西既能凈化我們的心靈，還能減少不易察覺的隱患。

不要用中文拼音做變量名

現在C#和Java都支持中文變量名，類名。可以試着玩一玩，但是真的不要用到項目中，不只是說中文，還有中文拼音。使用有意義的英文作為變量名更有利於溝通，和外國人溝通方便，和中國人溝通也方便。曾經看到有人設計數據庫，字段名全部使用中文拼音縮寫，令人費解，而且非常別扭，大概只有自己能看懂吧。

英文變量名也不要用a，b，c，d作為變量名，使用有意義的單詞全稱一眼就知道這個變量，這個類是做什么用的。大家都很忙，沒時間猜來猜去。

可用，清晰優雅，高效

具體到一個實際的功能，代碼是可用的，看起來清晰優雅的，運行起來高效的才是好代碼的標准。

要做到這三點，首先要明確需求，考慮全面一點，從正確性，邊界值，反例三個角度去思考問題，定下詳細的需求，掌握需求方的意圖。
其次，需要先做一個Demo，用於雙方進一步確認需求。沒有Demo，雙方都不是很確定對方有沒有get√到我的意思。有了Demo，絕大部分需求都可以確定下來了。一個粗糙的成品好過一個精美的半成品。不要過早優化，先把粗糙的成品做出來，后續慢慢優化。
最后，具體到代碼，很多時候都需要調試代碼，不要一上來就斷點調試，先看一遍代碼，檢查代碼邏輯，理一理思路，然后采用二分法設置斷點輸出日志，快速定位問題代碼。優化時，確定一個優化的基准，優化之后有對比，用數據來告訴別人優化的效果。

多寫代碼，多思考

多寫代碼，多思考；多喝熱水，多鍛煉。

好的代碼是在一定代碼量的基礎上積累起來的，寫的時候要多加思考，不能不知道自己在干什么。

程序員長時間坐在椅子上，對脊椎傷害很大，脖子僵硬。建議多喝熱水，多活動。寫代碼一小時就要停下來休息一下，走一走，動一動。多鍛煉身體，身體是革命的本錢。

轉載請注明出處：

http://blog.csdn.net/gane_cheng/article/details/52152497

http://www.ganecheng.tech/blog/52152497.html （瀏覽效果更好）