作為軟體開發者，我們可以開發低等級的軟體，但不能開發低質量的軟體。
那麼我們要怎麼去保證開發出高質量的軟體呢？這是我們一直關注的問題，而編碼規範正是實施質量保證的第一步。
在網上，其實也有很多**規範了，在官網上也有推薦的規範，可是為什麼我們再這裡還要這麼麻煩制定乙個屬於自己的規範呢？
其實這也是乙個暢談的話題了，每乙個公司甚至小到每乙個專案，都有著自己的規範，只用適合自己公司或者當前專案的規範，才是最好的規範。當然，現在在這裡，最重要的原因還是在於統一的問題。
在高質量的軟體中，你可以看到「架構的概念完整性」與「底層實現」之間的關係。「實現」與「架構」必須是清晰一致的，這種內在的、固有的一致性，需要編碼規範來維繫。如果沒有這種統一的約定，那麼我們做出的東西可能會充斥著各種不同的風格，顯得混亂且難以理解。團隊成員之間可能很不理解彼此之間的想法，甚至是相互抨擊。各種**風格上的差異會不斷擴大，而**質量則不斷下降。而且，團隊成員會花費時間在理解不同程式設計風格之間的差異，而沒有專注於真正應該解決的問題。這樣的時間消耗是難以接受的。所以，在每乙個高質量**的背後，一定存在著乙份優秀的編碼規範。
然而，也必須認識到編碼規範不是「神」。編碼規範僅僅是乙個全域性性質的規範，它只不過是一種程式設計約定，不能解決更深層次的問題。就像一篇格式漂亮但內容糟糕的**不能被發表一樣，你不能僅靠乙個規範來擺脫軟體作坊。而且，在編碼規範中不宜包含那些冗長的開發技巧。我認為，對於**是最佳實踐應該是**審查所要解決的，應該避免將編碼規範寫成一部關於重構的教科書。
您是否有因**雜亂冗餘而心生厭惡，您是否有過因**晦澀難懂而抓狂，您是因**低階的邏輯錯誤而憤概，您是否因**結構不合常規而需要到處查詢，您是否因看到幾百甚至上千行**的方法而望洋興嘆，您是否因**缺少注釋而猜測以及花很多時間去理清楚前後邏輯？
苦逼的我在這個星期閱讀公司裡面之前的專案**的時候，全部都遇到過了。本身乙個邏輯很簡單的東西，我花的時間竟然比看jd**程模組還要多，讓我真的很驚訝，今天我到回去再看了下jdk的源**，有了乙個很重大的發現。也就是下面的的問題所在。
**規範沒有什麼用處。這些規範都是官僚制度下產生的浪費大家的程式設計時間、影響人們開發效率的東西？
通過檢視jdk的源**，你可以看到，如此多的編碼規範—縮排，命名，檔案結構，注釋風格—這一切讓人出乎意料的能夠輕鬆的閱讀任意一段**，並輕易的看懂它們。
震驚了嗎？規範本身是乙個微不足道的東西，但它們卻起到了這麼大的作用。當你發現只通過看程式的基本語法結構就能讀懂一段**，這種時間上的節省不能不讓人震撼！
當你按照某種編碼規範進行程式設計時，必然會有某些地方讓你搖頭不爽，那麼這規範真的不行嗎？
肯定會在某些地方你的編碼風格會優於這些規範。但是，這不重要。在某些地方，編碼規範也有優於你的程式設計風格的時候。但是，這也不重要。只要這規範不是完全的不可理喻，在程式的可理解性上得到的好處會大大的補償你的損失。
要是真的不可理喻怎麼辦？提出來，大家一起商量解決方法。
這個**我只在這裡用到，別人是用不到的，也不會給別人用或者修改的了，所以就不用按照規範改了吧？
相信很多人都會這麼想吧，但是希望大家能夠記住這麼一句話。**不是一次性的，它需要重複的修改和重構，為未來寫點**。這句話可能大家會有疑問，什麼叫做為未來寫點**？簡單說吧，如果你現在的**寫的不好，然後後期維護的時候，不可讀，不可維護、不可拓展，那你是否就要重新寫一次這些功能的**，做重複的工作？但是如果現在我們按規範，寫好了高質量的**，以後就能直接用，從而減少了工作量，這樣，算不算為未來寫點**了呢？相信大家能懂的。
1.編寫目的
1) 為規範軟體開發人員的**編寫提供參考依據和統一標準
2) 在專案開發過程中的注意事項以及編碼規範，旨在提公升**的可讀性與可維護性，同時減少**出錯的機會。
1)提高可讀性「任何乙個人都能寫出計算機可以理解的**，唯有寫出人類容易理解的**，才是優秀的程式設計師。」編碼規範，幫助我們寫出人類容易理解的**，它為我們提供了最基本的模板，良好的編碼風格，使**具有一定的描述性，可以通過名字來獲取一些需要ide才能得到的提示，如可訪問性、繼承基類等
2)統一全域性，促進團隊協作開發軟體是乙個團隊活動，而不是個人的英雄主義。編碼規範，要求團隊成員遵守這一統一的全域性決策，這樣成員之間可以輕鬆地閱讀對方的**，所有成員正以一種清晰而一致的風格進行編碼。而且，開發人員也可以集中精力關注他們真正應該關注的問題——自身**的業務邏輯，與需求的契合度等區域性問題。
3)有助於知識傳遞，加快工作交接風格的相似性，能讓開發人員更迅速，更容易理解一些陌生的**，更快速地理解別人的**。因為，他和你的**風格是一樣的，你沒有必要對他的一些個性化風格進行揣測。這樣的好處是開發人員可以很快的接手專案組其他成員的工作，快速完成工作交接。
4)減少名字增生，降低維護成本在沒有規範的情況下，和容易為同一型別的例項起不同的名字。對於以後維護這些**程式設計師來說會產生疑惑
5)強調制數之間的關係，降低缺陷引人的機會命名可以表示一定的邏輯關係，是開發人員在使用時保持警惕，從而一定程度上減少缺陷被引人的機會
6)提高程式設計師的個人能力不可否認，每個程式設計師都應該養成良好的編碼習慣，而編碼規範無疑是教材之一。從乙個程式設計師的**本身能看出很多東西。所以，即便是為了自身發展，作為程式設計師也沒有理由抵制這種規則的存在。你可能沒有認識到，我們正默默地得益於編碼規範。
寫這篇博文，主要是因為最近的境遇導致的，關於本文的內容，也並非完全是我個人的感想，大部分是來自於網路上大家有的共同的疑問，我將它抽取出來，寫在這裡的，希望能夠引起大家的思考，對大家有所幫助。
1.meteorseed ：
2.mark cc ：
3.永無止境，上下求索 ：
編碼規範的幾點思考
實習企業格外注意編碼規範，當時覺得多此一舉，後來回味卻發現有很多奧妙的。1 邏輯判斷 習慣寫法 if a 0 規範寫法 if 0 a 分析 相信80 的人都遇到過少些 的情況，那麼 a 0 就成了賦值運算，除非const修飾，該式就成了用真式了，此類問題還不好發現。反觀第二種寫法，一旦少寫，必然報錯...
php 編碼規範哪些 php編碼規範
1.php 必須以完整的形式來定界 即不要使用php 短標籤 且保證在關閉標籤後不要有任何空格。2.當乙個字串是純文字組成的時候 即不含有變數 則必須總是以單引號 作為定界符。例如 a example string 3.變數替換中的變數只允許用 變數名 的形式。例如 greeting hello n...
php 編碼規範哪些 PHP編碼規範
很多初學者對編碼規範不以為然，認為對程式開發沒有什麼幫助，甚至因為要遵循規範而影響了學習和開發的進度。或者因為經過一段時間的使用，已經形成了自己的一套風格，所以不願意去改變。這種想法是很危險的。如今的 web 開發，不再是乙個人就可以全部完成的，尤其是一些大型的專案，往往需要十幾人，甚至幾十人來共同...