規(guī)范的命名對于閱讀程序是如此重要，本文開篇就不得不提到它。在閱讀代碼時，理解一個變量和函數(shù)都是從名字開始的。它是什么？它的職責是什么？這些問題從名字就應該看出來，如果名稱需要注釋來補充，那就不算是好名字。

例如：將變量名

修改為：

將函數(shù)名

修改為：

寧可名字取長一點，也不要起個模糊的名字。一個清楚的變量名還會帶來可搜索的好處。即使在寫二分算法時，也盡量別用"l"和"r"來指代左右邊界，換成"left"和"right"會更好。

不過，變量名也并非越長越好，去除變量名中的冗余也是一個好習慣。Variable 一詞永遠不應當出現(xiàn)在變量名中，Table 一詞永遠不應當出現(xiàn)在表名中。 nameString 與 name 沒區(qū)別，moneyAmount 與 money 沒區(qū)別， customerInfo 與 customer 沒區(qū)別， theMessage 也與 message 沒區(qū)別。

命名風格應該保持統(tǒng)一，每個概念對應一個詞。如果一堆代碼中既有 Controller，又有 Manager，還有 Driver，Presenter，就會令人困惑：他們之間有什么區(qū)別？為什么不全用 Controller？如果同一概念可被多個詞語描述，請確定其中一個名字，并在你的代碼中一以貫之。

總之，取一個精準的名字是一名優(yōu)秀程序員的基本功。從一開始學習編程時，每次取名都應仔細思考，切不可草草了事。

同樣的代碼，僅僅是加上空格與縮進就能看起來更美觀?，F(xiàn)代化的 IDE 都有代碼格式化快捷鍵，在代碼敲完后隨時格式化，并去掉多余的空行，是一個讓代碼保持美觀的好習慣。

斐波那契程序員：每天都在修復昨天和前天的 bug

你是否有過這樣的經(jīng)歷：代碼刪了又寫，寫了又刪。在敲代碼之前，先問自己一個問題：我寫下的這行代碼是真的能用上的嗎？會不會有邏輯漏洞？思考清楚業(yè)務流程之后再寫代碼，往往事半功倍。

以筆者親身經(jīng)歷過的一個項目為例，項目已經(jīng)做了一年， 除了三方庫，代碼量共有兩萬行，平均算下來，開發(fā)者一年來每天只需要寫 55 行代碼。這樣看來，開發(fā)者的每一天都差不多是”很閑的“，然而開發(fā)者每天都忙得不得了，從早到晚都在碼代碼。這些代碼量如果純粹敲出來，最多十個小時就可以完成。我們應該用大部分的時間思考代碼邏輯，不要花大量時間將代碼刪了又寫，寫了又刪。磨刀不誤砍柴工，事先做好全面的考慮，爭取讓寫下的每一行代碼都有價值。

程序員的時間分配

梳理代碼邏輯是有一定方法的，例如：

• 通過畫圖工具先將邏輯畫出來，流程圖、UML 圖、時序圖、思維導圖都能對你有所幫助。
• 寫接口之前先模擬出假數(shù)據(jù)，測試邏輯層沒有問題之后再寫接口，可以避免寫出的接口不合適。
• 善于寫偽代碼，將程序需要實現(xiàn)的每個步驟先用抽象的偽代碼寫出來。具體實現(xiàn)時再將偽代碼細化。
• 寫代碼之前先編寫測試用例，將你期望的輸入輸出寫在測試用例中