《團隊-團隊編程項目作業名稱-代碼設計規範》
如何才能寫出好代碼呢？
在一次講座上，我聽了一位編程大神的看法，在這裏分享給大家。
好的代碼應該至少具備下面這6個特點：
- 使用空行來分割邏輯
- 使用註釋和花括號
- 不用的代碼和引用刪除
- 不要用中文拼音做變量名
- 可用，清晰優雅，高效
- 多寫代碼，多思考
使用空行來分割邏輯
一般代碼超過30行左右，我們就在考慮，要不要把這些代碼封裝到一個方法中去。但是即使把這一大段代碼扔到一個方法中去，在主函數裏調用這個方法，也不能保證以後不會修改這個方法了。所以為了自己和他人，還是有必要對比較長的代碼做一些處理。
一般即使是一個方法裏面的代碼，邏輯也是可以分成一小塊一小塊的，這個時候我們在這些邏輯中間加上空行，就能告訴別人，我這個代碼這裏，兩個空行中間的代碼關聯比較大。
使用註釋和花括號
在軟件開發的生命周期中，文檔應該是一直伴隨著的。這樣，後面接手的人看文檔就知道當時發生了什麽。如果項目組有使用文檔來規範開發，那就要去遵守這個規定。但是文檔也有一個問題，就是代碼修改之後就要去修改文檔，萬一文檔沒有更新，接手的人反而會受到誤導。
文檔是個好習慣，在堅持更新項目文檔的同時，還要記得更新代碼的註釋，敲完代碼後隨手加上的簡短的幾個字，會提高看代碼的效率好多倍。
當你焦頭爛額的猜測原來編碼的人是怎麽想的時候，看到下面添加了註釋的代碼，是不是有一種謝天謝地的感覺。
C++默認方式，更容易看清代碼層次；Java默認方式減少占用的行數。
個人更加傾向於上下對齊式。但是個人意見需要服從團隊約定。你所在的團隊使用哪種方式，你就要使用哪種方式，和大家保持統一。
並且這兩種默認方式在集成開發環境IDE中都是可以調節的。比如Java的代碼，我平時這樣排版。
不用的代碼和引用刪除
我們寫代碼時，需要修改代碼時經常註釋之前的代碼，然後把自己的代碼加上去。但是又不確定自己的代碼100%正確，不敢刪掉註釋的代碼，因為可能還會換為原來的代碼。
這樣導致的後果是以後如果沒有看出註釋代碼的問題，反而覺得很有道理的話，真的會將你的代碼重新用註釋代碼換回來。
我們寫代碼要相信自己，該刪的時候就要刪掉。要學會使用SVN或者是Git來進行版本控制。即使當前版本刪掉了，回滾到之前版本依然能夠找回來。大可不必擔心真的會刪掉了，這樣萬一有什麽變故，也還是能夠找回來的。
我們也會經常註意到編輯器行首有很多黃色的感嘆號warning提示。雖然不影響程序正常運行，但是看著就是有點不雅觀，而且過多沒有使用的引用，或者外部包，框架，庫等等也會拖慢程序的運行速度。幹掉這些無用的東西既能凈化我們的心靈，還能減少不易察覺的隱患。
不要用中文拼音做變量名
現在C#和Java都支持中文變量名，類名。可以試著玩一玩，但是真的不要用到項目中，不只是說中文，還有中文拼音。使用有意義的英文作為變量名更有利於溝通，和外國人溝通方便，和中國人溝通也方便。曾經看到有人設計數據庫，字段名全部使用中文拼音縮寫，令人費解，而且非常別扭，大概只有自己能看懂吧。
英文變量名也不要用a，b，c，d作為變量名，使用有意義的單詞全稱一眼就知道這個變量，這個類是做什麽用的。大家都很忙，沒時間猜來猜去。
可用，清晰優雅，高效
具體到一個實際的功能，代碼是可用的，看起來清晰優雅的，運行起來高效的才是好代碼的標準。
- 要做到這三點，首先要明確需求，考慮全面一點，從正確性，邊界值，反例三個角度去思考問題，定下詳細的需求，掌握需求方的意圖。
- 其次，需要先做一個Demo，用於雙方進一步確認需求。沒有Demo，雙方都不是很確定對方有沒有get√到我的意思。有了Demo，絕大部分需求都可以確定下來了。一個粗糙的成品好過一個精美的半成品。不要過早優化，先把粗糙的成品做出來，後續慢慢優化。
- 最後，具體到代碼，很多時候都需要調試代碼，不要一上來就斷點調試，先看一遍代碼，檢查代碼邏輯，理一理思路，然後采用二分法設置斷點輸出日誌，快速定位問題代碼。優化時，確定一個優化的基準，優化之後有對比，用數據來告訴別人優化的效果。
多寫代碼，多思考
多寫代碼，多思考；多喝熱水，多鍛煉。
好的代碼是在一定代碼量的基礎上積累起來的，寫的時候要多加思考，不能不知道自己在幹什麽。
程序員長時間坐在椅子上，對脊椎傷害很大，脖子僵硬。建議多喝熱水，多活動。寫代碼一小時就要停下來休息一下，走一走，動一動。多鍛煉身體，身體是革命的本錢。
《團隊-團隊編程項目作業名稱-代碼設計規範》