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

例如：將變量名

修改為：

將函數(shù)名

修改為：

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

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

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

總之，取一個(gè)精準(zhǔn)的名字是一名優(yōu)秀程序員的基本功。從一開始學(xué)習(xí)編程時(shí)，每次取名都應(yīng)仔細(xì)思考，切不可草草了事。

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

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

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

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

程序員的時(shí)間分配

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

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