如何編寫更棒的代碼：11個核心要點

　　英文原文：11 tips for better code

　　作為一個合格的程序員，有太多的理由促使你去編寫干凈利落且可讀性強的代碼。最重要的是因為你編寫的代碼，將來會有很多人一次次地閱讀。當你有 一天回過頭來看自己的代碼時，你就會明白編寫優雅的代碼是多么的重要。另外，如果別人來閱讀你編寫的代碼，你是否想知道別人看到那些爛代碼無比抓狂的感 受。因此，花多一點的時間去編寫優雅的代碼，將來說不定會給你節省更多的時間。

　　那么，如何編寫更棒的代碼，下面是 11 條基本規則：

1. 保持方法簡短扼要
2. 永遠永遠不要將同一個變量用于不同的目的
3. 盡可能讓變量和方法的名稱能夠描述要實現的功能
4. 盡可能將變量定義在最靠近它們的地方
5. 不要出現讓人費解的數字
6. 要像對待朋友一樣對待你擅長的語言
7. 不要逆常規而行
8. 千萬小心過早的優化代碼
9. 要常常重構經過測試的代碼
10. 不要沉溺于過度的設計技巧
11. 隨時隨地學習新的知識

　　下面我們來對每一點詳細展開介紹。

　　1、保持方法簡短扼要

　　盡管很多人都遵循這條規則，但是它依然很重要。總的來說，編寫的方法最好能在首屏完全顯示。試想，如果你需要滾動頁面才能看到整一個方法，那是 一件多么分散注意力的事情。一個方法最好能保持在 5 – 20 行之間，當然，你也要視具體情況而定，并不是一概而論的。對于 getter 和 setter 方法，通常只需一行代碼，所以它們看起來更像是類成員的存取訪問器。

　　2、永遠永遠不要將同一個變量用于不同的目的

　　一個變量應該只能被用于一個目的，我們可以通過使用常量（C++中用 const 標識，Java 中用 final 標識），幫助編譯器優化代碼編譯，也可以向程序標識“這個變量是不能被改變的”，這樣我們編寫的代碼就有更好的可讀性。

　　3、盡可能讓變量和方法的名稱能夠描述要實現的功能

　　一段通俗易懂的程序代碼，應該是任何人只要看了代碼，就能明白程序是用來干嘛的。所以我建議大家盡量少用縮寫，除非是程序界公認的簡寫習慣，像下面的簡寫習慣：

src - source
pos - position
prev - previous

　　如果你覺得描述性的簡寫方式沒有價值，你可以比較一下n, ns, nsisd 和 numTeamMembers, seatCount, numSeatsInStadium

　　4、盡可能將變量定義在最靠近它們的地方

　　當你在蓋房子的時候，總不希望把錘子放在別人家的院子里吧，相反，你會把蓋房的工具放得盡可能近，定義變量也是同樣的道理。

 int foo = 3;
int bar = 5;
// bunch of code that uses "bar"
// but doesn't care about "foo"
// ... 
baz (foo);

　　我們可以這樣重構代碼：

 int bar = 5;
// bunch of code that use "bar"
// but doesn't care about "foo"
// ... int foo = 3;
baz (foo);

　　當你把變量的聲明跟使用它的地方相隔太遠的時候（甚至是超過一屏），那的確會給你帶來很大的麻煩。你會經常滾動頁面去尋找這個變量，導致你很難在大腦中保持代碼之間的連貫性。

　　5、不要出現讓人費解的數字

　　任何時候，你要比較一些常量時，都要將它們定義成 constant 類型。團隊之間調試代碼時最讓人頭疼是出現下面的代碼：

il < 4384

　　把它替換成下面的代碼該多好：

inputLength < MAX_INPUT_LENGTH

　　6、要像對待朋友一樣對待你擅長的語言

　　學習一種新的編程語言是一件很有趣的事情，從中你可以用很酷的方式學到新東西。還有就是讓一個對某種語言很專業的人去學另外一種語言，很多時候 會讓人心有余而力不足。舉個例子，你讓一個 Java 大牛去學 Ruby，他應該會用 Ruby 的方式去解決問題，而不是繼續沿用 Java 的解決問題的思想。

　　當你需要循環輸出 5 遍”Hello World“時，Java 代碼應該會是這樣：

for (int i = 0; i < 5; i++) {
    System.out.println ("Hello world!");
}

　　但是用 Ruby，你也許會這樣寫：

for i in (0..5)
  puts "Hello world!" end

　　這些看上去都很不錯，但是最完美的方式可能是下面這樣：

5.times { puts "Hello world!" }

　　7、不要逆常規而行

　　每一種編程語言都有自己的約束習慣，總的來說，大家對 Java 的編程習慣可能會了解得比較多，我們一起來看看其中的一些習慣：

1. 方法名以小寫字母開頭，后面緊跟的是大寫字母開頭的單詞，比如 veryLongVariableName。
2. 類名一般都是大寫字母開頭的單詞組合。
3. 常量的命名都是大寫字母的單詞，之間用下劃線隔開，比如 MY_CONSTANT
4. 左大括號應該跟 if 在同一行

　　只有在迫不得已的時候才能打破這種規則，千萬不要因為不喜歡這種做法而違背已經約定好的編碼習俗。如果你身為團隊一員，想改變一些編碼規則的話，那也可以，不過當你把自己的代碼分享給沒有你這種習慣的隊友的時候，棘手的問題會迎面而來。

　　8、千萬小心過早的優化代碼

　　過早的優化是所有問題的根源，至少電視上是這么說的…你的首要任務是編寫容易理解的代碼，而不要求你能很快寫出來。除非你的程序運行很慢，否則談優化都是為時太早。如果你想優化你的程序，那么得先找出程序的問題，這就是我們需要 profilers 這個工具的原因。

　　在沒有找到問題源頭就去優化代碼，這樣做你所要付出的代價就是破壞了程序的結構，至少會喪失程序的可讀性。如果你發現程序運行緩慢了，也不要盲目地重構代碼，要先找到導致運行慢的根本原因。

　　千萬不要傻乎乎地去解決根本不存在的問題。

　　9、要常常重構經過測試的代碼

　　世上沒有絕對完美的事情。盡管你認為自己的代碼已經寫得非常完美了，過一段時間也要經常去看看它，也許那時你會對自己大罵：”怎么會那么傻！”

　　有一種提高代碼質量的方法，那就是經常重構通過測試的代碼。所謂通過測試，我指的是程序要能正常工作，你可以通過自動化測試或者手動測試來確保這一點。

　　首先你要確保程序能夠正常運行，第一次我們并不需要寫出多么完美的程序，能用就行，接下來我們可以慢慢重構，讓它逐漸變得完美。這種開發方式很 有 TDD 的味道，關鍵在于你需要熟悉重構的每一個環節。如果你熟練使用一些高級的 IDE，像 IntelliJ IDEA，那你的重構工作將會簡單很多。

　　重構完以后，也許你會碰到很多這樣那樣的問題，甚至會破壞正常的程序，這就是我們要利用自動化測試的原因了。當你重構完以后，跑一遍單元測試就能避免這些令人頭疼的問題了。

　　10、不要沉溺于過度的設計技巧

　　當我第一次接觸到設計模式這一概念時，我覺得自己找到了“圣杯”。這些精妙的設計思想可以讓你工作更加順利，也可以讓你的設計淺顯易懂，因為你 可以簡單的說“我使用了觀察者模式”，而不同大費周章的解釋一通。然而問題來了，由于有些問題看起來太自然太簡單了，你會把那些設計模式的思想應用到任何 地方，為什么不把這個類設計成單例模式（singleton）？干嘛不去創建一些工廠類呢？

　　于是用 80 行代碼就能完成的腳本，結果你用了 10 個類，15 個接口和一堆泛型和注釋，這其中的 97% 代碼并沒有做實質上的事情。設計模式雖然非常有用，可以幫助你簡化設計，但是這并不是說你可以到處使用它們。你可以使用設計模式，但是不能將它濫用了。

　　11、隨時隨地學習新的知識

　　編程就是一項隨時學習新事物的工作，當你學到了新的類庫或者編程語言時，你會迫不及待地丟掉老的代碼，進而去重寫它們。然而有很多理由說明你不該這么做。

　　將一個新的類庫或者框架應用到現有的項目中就會出現類似的問題。比如說你正在為一個 Web 項目寫 Javascript，但是中間你發現了 jQuery，這時候你會迫不及待想把 jQuery 應用進去，而丟掉原來的 Javascript 代碼，即便你根本沒用 jQuery 寫過任何項目。

　　最好的方式是你先用 jQuery 學著寫一些簡單的例子，把你項目中要用到的技術都學會。比如說你想要用 AJAX？就先在項目之外寫一些關于 AJAX 的簡單例子，等到完全掌握了，就可以將老代碼從項目中移除。

　　如果你熱衷于編程，我強烈推薦你閱讀 Steve McConnell 編寫的《Code Complete》，它將永遠改變你的編程思維。

　　譯文鏈接：http://www.html5tricks.com/11-tips-to-coding-better.html

　　翻譯作者：蔣麗麗