01

關于馬化騰編碼的水平，網絡上曾有這樣一個段子：

曾經和pony（馬化騰）一起寫過代碼。當時我、pony、馬克3人擠在一個只有10個位置的房間里，埋頭開發。馬克當時負責排查兩個bug，跟進了10個月，沒有一點進展，下樓準備買點瑞士卷吃，消消愁。回來發現pony光著膀子，啃著個豬蹄兒，站在陽臺，望著寂靜的夜，回頭冷靜地和馬克說了句：“bug我幫你處理好了。”

可見老馬的編碼水平之高，當然，這只是個段子。但據說當年創業時，公司主頁是馬化騰自己親手制作的。

關于他編碼是不是最好的，我們不知道；但可以肯定的是，他一定是通過軟件掙錢掙得最多的那位程序員。

02

無獨有偶，互聯網界的精英，大多數是技術出身，譬如雷軍、李彥宏、周鴻祎等，幾乎都是編程高手。作為京東首席CEO，劉強東編碼水平也備受關注。

知乎上，有人曾提問過這樣一個問題：

劉強東的代碼水平如何?

有網友這樣回復：

劉強東在一次講座上，稱自己在校大三的時候，也就是1995年左右，他給別人寫代碼，一個晚上就能賺5萬。

95年一個晚上5萬，那是什么概念。

至于劉強東編碼的水平究竟怎樣，是不是像上面網友形容的那樣，可以一個晚上賺5萬，我們無從而知。

但可以肯定的是，無論是馬化騰還是劉強東，所編寫的代碼應該很規范。

不知你有沒有類似這樣的這樣的經歷：

回頭看看自己一年前編寫的代碼，驚訝地發現，哇哈，如此不規范的代碼，是誰編寫的？確定是我寫的嗎？我能寫出這樣慘目忍睹的代碼？分分鐘鐘懷疑人生。

代碼規范的重要性我們都知道，但要真正做好，還需要我們在實踐中慢慢的累積，不斷修煉。

03

如果代碼沒有統一的規范，每個人都按照自己掌握理解的那一套，那么整個項目的代碼很可能就會出現風格迥異。即使是分工明細，每個人負責一個模塊，等到要整合代碼的時候就尷尬了。

很多時候，并非程序的算法有多復雜，或是邏輯多么復雜，而是因為代碼不規范，越讀越費勁，把精力都耗在這里了。

統一的代碼規范可使得代碼可讀性大大提高， 在團隊的合作開發中是非常有益而且很有必要。

04

項目維護工作不僅讀懂源碼，而且還需要在原有源碼基礎上作出修改。如果沒有統一代碼規范，很可能會出現這種現象：

張三完成開發以后，李四進行維護加一段代碼，過一段時間王五又加一段代碼。原本一個很普通的需求，經歷了N次迭代和修改，已經形成了巨大的功能。直到有一天，張三、李四、王五都辭職了，新來的員工看到那一大堆沒有統一規范的代碼。想死的心都有了。
隨著不斷迭代版的維護成本越來越高，從而形成惡性循環。程序背后的架構設計或模式固然重要，但良好的命名也不容忽視。不規范的命名不僅讓我們對代碼難以理解，更糟糕的是，會誤導我們的思維，導致對代碼的理解有偏差。

相反，良好的命名規范，則可以讓我們的代碼更加容易讀懂，也能向讀者正確表達事物以及邏輯的本質，閱讀命名規范的源碼理解沒有那么費勁，會有一種享受的感覺。

有人喜歡對控件textview1，textview2，textview3、，textview4類似這樣的命名，甚至還對其添加注釋。

有人可能認為注釋越多，其他人看到的就會越好。其實不然，注釋過多，或是一些冗余注釋，反而會影響源碼的可讀性。如果我們良好的命名規范，結合了需要和命名。它可以省去許多不必要的注釋。

對于方法命名，首字母一會兒大寫，一會兒小寫；一會兒全稱一會兒簡寫；一會兒駝峰命名法一會兒匈牙利命名法。

當然，起一個好的名字不是件容易的事情。首先，既要有盡量多的提供變量信息，又要盡可能的保證名字短小精悍，還不能為了短小而隨意采用縮寫而導致閱讀障礙，另外還要盡量保證以后程序更新后名稱仍然能很好的描述其內容。

在編寫代碼中，要盡可能的遵守一個良好的命名規范，并且不停地的調整學習命名，從而逐漸掌握起一個良好名字的能力。

05

知道了代碼規范的重要性，但有時候迫于項目趕進度壓力，有的因為繁瑣的規范作出很多額外的工作，影響了項目開發進度，而漸漸被忽略。

規范不是對開發的制約，而確實是有助于提高開發效率的，最大的受益人其實還是自己。

不知你有沒有類似這樣的經歷：

很多的時候閱讀自己的代碼，需要花費很多時間？
尤其是出現bug的時候需要逐行的debug？
自己編寫的代碼過了一段時間后再來看自己都亂了頭緒。回到前面說的疑問，這代碼是我自己寫的嗎？
我們應該做的就是規范開發，減少自己出現的錯誤。很多時候項目的壓力一部分也是由于前期開發中遺留的眾多的問題。

那些看似無用的東西要經過我們慢慢地累積由量變達到質變的時候，相信你能體會到其價值所在。

養成良好的代碼規范不是為了別人，也不是為了公司，而是為了提高自己的編程修養，提高自己認識事物的能力。讓自己編寫的代碼可維護性更好、可重用性和可擴展性更強。

接手別人項目時，最讓你最難以接受的是什么？沒注釋，代碼亂？代碼冗余？架構拓展差？歡迎留言！

【END】