編碼規範那些思考

1、問與答

做爲軟件開發者，咱們能夠開發低等級的軟件，但不能開發低質量的軟件。

　　那麼咱們要怎麼去保證開發出高質量的軟件呢？這是咱們一直關注的問題，而編碼規範正是實施質量保證的第一步。

 

在網上，其實也有不少代碼規範了，在官網上也有推薦的規範，但是爲何咱們再這裏還要這麼麻煩制定一個屬於本身的規範呢？

　　其實這也是一個暢談的話題了，每個公司甚至小到每個項目，都有着本身的規範，只用適合本身公司或者當前項目的規範，纔是最好的規範。固然，如今在這裏，最重要的緣由仍是在於統一的問題。
　　在高質量的軟件中，你能夠看到「架構的概念完整性」與「底層實現」之間的關係。「實現」與「架構」必須是清晰一致的，這種內在的、固有的一致性，須要編碼規範來維繫。若是沒有這種統一的約定，那麼咱們作出的東西可能會充斥着各類不一樣的風格，顯得混亂且難以理解。團隊成員之間可能很不理解彼此之間的想法，甚至是相互抨擊。各類代碼風格上的差別會不斷擴大，而代碼質量則不斷降低。並且，團隊成員會花費時間在理解不一樣編程風格之間的差別，而沒有專一於真正應該解決的問題。這樣的時間消耗是難以接受的。因此，在每個高質量代碼的背後，必定存在着一份優秀的編碼規範。
　　然而，也必須認識到編碼規範不是「神」。編碼規範僅僅是一個全局性質的規範，它只不過是一種編程約定，不能解決更深層次的問題。就像一篇格式漂亮但內容糟糕的論文不能被髮表同樣，你不能僅靠一個規範來擺脫軟件做坊。並且，在編碼規範中不宜包含那些冗長的開發技巧。我認爲，對於代碼是最佳實踐應該是代碼審查所要解決的，應該避免將編碼規範寫成一部關於重構的教科書。

 

您是否有因代碼雜亂冗餘而心生厭惡，您是否有過因代碼晦澀難懂而抓狂，您是因代碼低級的邏輯錯誤而憤概，您是否因代碼結構不合常規而須要處處查找，您是否因看到幾百甚至上千行代碼的方法而望洋興嘆，您是否因代碼缺乏註釋而猜想以及花不少時間去理清楚先後邏輯？

　　苦逼的我在這個星期閱讀公司裏面以前的項目代碼的時候，所有都遇到過了。自己一個邏輯很簡單的東西，我花的時間居然比看jdk線程模塊還要多，讓我真的很驚訝，今天我到回去再看了下jdk的源代碼，有了一個很重大的發現。也就是下面的的問題所在。

 

代碼規範沒有什麼用處。這些規範都是官僚制度下產生的浪費你們的編程時間、影響人們開發效率的東西？

　　經過查看jdk的源代碼，你能夠看到，如此多的編碼規範—縮進，命名，文件結構，註釋風格—這一切讓人出乎意料的可以輕鬆的閱讀任意一段代碼，並輕易的看懂它們。
　　震驚了嗎？規範自己是一個微不足道的東西，但它們卻起到了這麼大的做用。當你發現只經過看程序的基本語法結構就能讀懂一段代碼，這種時間上的節省不能不讓人震撼！

 

當你按照某種編碼規範進行編程時，必然會有某些地方讓你搖頭不爽，那麼這規範真的不行嗎？

　　確定會在某些地方你的編碼風格會優於這些規範。可是，這不重要。在某些地方，編碼規範也有優於你的編程風格的時候。可是，這也不重要。只要這規範不是徹底的不可理喻，在程序的可理解性上獲得的好處會大大的補償你的損失。
　　要是真的不可理喻怎麼辦？提出來，你們一塊兒商量解決方法。

 

這個代碼我只在這裏用到，別人是用不到的，也不會給別人用或者修改的了，因此就不用按照規範改了吧？

　　相信不少人都會這麼想吧，可是但願你們可以記住這麼一句話。代碼不是一次性的，它須要重複的修改和重構，爲將來寫點代碼。這句話可能你們會有疑問，什麼叫作爲將來寫點代碼？簡單說吧，若是你如今的代碼寫的很差，而後後期維護的時候，不可讀，不可維護、不可拓展，那你是否就要從新寫一次這些功能的代碼，作重複的工做？可是若是如今咱們按規範，寫好了高質量的代碼，之後就能直接用，從而減小了工做量，這樣，算不算爲將來寫點代碼了呢？相信你們能懂的。

 2、概述

1.編寫目的
   1) 爲規範軟件開發人員的代碼編寫提供參考依據和統一標準
   2) 在項目開發過程當中的注意事項以及編碼規範，旨在提高代碼的可讀性與可維護性，同時減小代碼出錯的機會。

2.編碼規範的好處

   1) 提升可讀性 「任何一我的都能寫出計算機能夠理解的代碼，惟有寫出人類容易理解的代碼，纔是優秀的程序員。」編碼規範，幫助咱們寫出人類容易理解的代碼，它爲咱們提供了最基本的模板，良好的編碼風格，使代碼具備必定的描述性，能夠經過名字來獲取一些須要IDE才能獲得的提示，如可訪問性、繼承基類等

   2) 統一全局，促進團隊協做 開發軟件是一個團隊活動，而不是我的的英雄主義。編碼規範，要求團隊成員遵照這一統一的全局決策，這樣成員之間能夠輕鬆地閱讀對方的代碼，全部成員正以一種清晰而一致的風格進行編碼。並且，開發人員也能夠集中精力關注他們真正應該關注的問題——自身代碼的業務邏輯，與需求的契合度等局部問題。

   3) 有助於知識傳遞，加快工做交接 風格的類似性，能讓開發人員更迅速，更容易理解一些陌生的代碼，更快速地理解別人的代碼。由於，他和你的代碼風格是同樣的，你沒有必要對他的一些個性化風格進行揣測。這樣的好處是開發人員能夠很快的接手項目組其餘成員的工做，快速完成工做交接。 

   4) 減小名字增生，下降維護成本 在沒有規範的狀況下，和容易爲同一類型的實例起不一樣的名字。對於之後維護這些代碼程序員來講會產生疑惑

   5) 強調變量之間的關係，下降缺陷引人的機會 命名能夠表示必定的邏輯關係，是開發人員在使用時保持警戒，從而必定程度上減小缺陷被引人的機會

   6) 提升程序員的我的能力 不能否認，每一個程序員都應該養成良好的編碼習慣，而編碼規範無疑是教材之一。從一個程序員的代碼自己能看出不少東西。因此，即使是爲了自身發展，做爲程序員也沒有理由抵制這種規則的存在。你可能沒有認識到，咱們正默默地得益於編碼規範。

3、感謝語

　　寫這篇博文，主要是由於最近的境遇致使的，關於本文的內容，也並不是徹底是我我的的感想，大部分是來自於網絡上你們有的共同的疑問，我將它抽取出來，寫在這裏的，但願可以引發你們的思考，對你們有所幫助。

　　最後，感謝下被我摘取了內容的幾個博客的做者，順便附上他們的連接，你們也能夠直接到他們的博客上看原文：

　　1.MeteorSeed ：http://www.cnblogs.com/MeteorSeed/archive/2012/03/21/2404656.html

　　2.Mark CC ：http://www.aqee.net/google-coding-standards/

　　3.永無止境，上下求索 ：http://blog.csdn.net/kimylrong/article/details/7700311