反復(fù)推敲代碼

寫優(yōu)雅的代碼

寫模塊化的代碼

• 避免寫太長的函數(shù)。如果發(fā)現(xiàn)函數(shù)太大了，就應(yīng)該把它拆分成幾個更小的。通常我寫的函數(shù)長度都不超過40行。對比一下，一般筆記本電腦屏幕所能容納的代碼行數(shù)是50行。我可以一目了然的看見一個40行的函數(shù)，而不需要滾屏。只有40行而不是50行的原因是，我的眼球不轉(zhuǎn)的話，最大的視角只看得到40行代碼。
  如果我看代碼不轉(zhuǎn)眼球的話，我就能把整片代碼完整的映射到我的視覺神經(jīng)里，這樣就算忽然閉上眼睛，我也能看得見這段代碼。我發(fā)現(xiàn)閉上眼睛的時候，大腦能夠更加有效地處理代碼，你能想象這段代碼可以變成什么其它的形狀。40行并不是一個很大的限制，因為函數(shù)里面比較復(fù)雜的部分，往往早就被我提取出去，做成了更小的函數(shù)，然后從原來的函數(shù)里面調(diào)用。

• 制造小的工具函數(shù)。如果你仔細觀察代碼，就會發(fā)現(xiàn)其實里面有很多的重復(fù)。這些常用的代碼，不管它有多短，提取出去做成函數(shù)，都可能是會有好處的。有些幫助函數(shù)也許就只有兩行，然而它們卻能大大簡化主要函數(shù)里面的邏輯。
  有些人不喜歡使用小的函數(shù)，因為他們想避免函數(shù)調(diào)用的開銷，結(jié)果他們寫出幾百行之大的函數(shù)。這是一種過時的觀念?，F(xiàn)代的編譯器都能自動的把小的函數(shù)內(nèi)聯(lián)（inline）到調(diào)用它的地方，所以根本不產(chǎn)生函數(shù)調(diào)用，也就不會產(chǎn)生任何多余的開銷。
  同樣的一些人，也愛使用宏（macro）來代替小函數(shù)，這也是一種過時的觀念。在早期的C語言編譯器里，只有宏是靜態(tài)“內(nèi)聯(lián)”的，所以他們使用宏，其實是為了達到內(nèi)聯(lián)的目的。然而能否內(nèi)聯(lián)，其實并不是宏與函數(shù)的根本區(qū)別。宏與函數(shù)有著巨大的區(qū)別（這個我以后再講），應(yīng)該盡量避免使用宏。為了內(nèi)聯(lián)而使用宏，其實是濫用了宏，這會引起各種各樣的麻煩，比如使程序難以理解，難以調(diào)試，容易出錯等等。

• 每個函數(shù)只做一件簡單的事情。有些人喜歡制造一些“通用”的函數(shù)，既可以做這個又可以做那個，它的內(nèi)部依據(jù)某些變量和條件，來“選擇”這個函數(shù)所要做的事情。比如，你也許寫出這樣的函數(shù)：
  void foo() {
  ?if (getOS().equals("MacOS")) {
  ? ?a();
  ?} else {
  ? ?b();
  ?}
  ?c();
  ?if (getOS().equals("MacOS")) {
  ? ?d();
  ?} else {
  ? ?e();
  ?}
  }
  寫這個函數(shù)的人，根據(jù)系統(tǒng)是否為“MacOS”來做不同的事情。你可以看出這個函數(shù)里，其實只有c()是兩種系統(tǒng)共有的，而其它的a(), b(), d(), e()都屬于不同的分支。
  這種“復(fù)用”其實是有害的。如果一個函數(shù)可能做兩種事情，它們之間共同點少于它們的不同點，那你最好就寫兩個不同的函數(shù)，否則這個函數(shù)的邏輯就不會很清晰，容易出現(xiàn)錯誤。其實，上面這個函數(shù)可以改寫成兩個函數(shù)：
  void fooMacOS() {
  ?a();
  ?c();
  ?d();
  }
  和
  void fooOther() {
  ?b();
  ?c();
  ?e();
  }
  如果你發(fā)現(xiàn)兩件事情大部分內(nèi)容相同，只有少數(shù)不同，多半時候你可以把相同的部分提取出去，做成一個輔助函數(shù)。比如，如果你有個函數(shù)是這樣：
  void foo() {
  ?a();
  ?b()
  ?c();
  ?if (getOS().equals("MacOS")) {
  ? ?d();
  ?} else {
  ? ?e();
  ?}
  }
  其中a()，b()，c()都是一樣的，只有d()和e()根據(jù)系統(tǒng)有所不同。那么你可以把a()，b()，c()提取出去：
  void preFoo() {
  ?a();
  ?b()
  ?c();
  然后制造兩個函數(shù)：
  void fooMacOS() {
  ?preFoo();
  ?d();
  }
  和
  void fooOther() {
  ?preFoo();
  ?e();
  }
  這樣一來，我們既共享了代碼，又做到了每個函數(shù)只做一件簡單的事情。這樣的代碼，邏輯就更加清晰。

• 避免使用全局變量和類成員（class member）來傳遞信息，盡量使用局部變量和參數(shù)。有些人寫代碼，經(jīng)常用類成員來傳遞信息，就像這樣：
  class A {
  ? String x;
  
  ? void findX() {
  ? ? ?...
  ? ? ?x = ...;
  ? }
  
  ? void foo() {
  ? ? findX();
  ? ? ...
  ? ? print(x);
  ? }
  }
  首先，他使用findX()，把一個值寫入成員x。然后，使用x的值。這樣，x就變成了findX和print之間的數(shù)據(jù)通道。由于x屬于class A，這樣程序就失去了模塊化的結(jié)構(gòu)。由于這兩個函數(shù)依賴于成員x，它們不再有明確的輸入和輸出，而是依賴全局的數(shù)據(jù)。findX和foo不再能夠離開class A而存在，而且由于類成員還有可能被其他代碼改變，代碼變得難以理解，難以確保正確性。
  如果你使用局部變量而不是類成員來傳遞信息，那么這兩個函數(shù)就不需要依賴于某一個class，而且更加容易理解，不易出錯：
  String findX() {
  ? ?...
  ? ?x = ...;
  ? ?return x;
  }
  void foo() {
  ? String x = findX();
  ? print(x);
  }

寫可讀的代碼

1. 使用有意義的函數(shù)和變量名字。如果你的函數(shù)和變量的名字，能夠切實的描述它們的邏輯，那么你就不需要寫注釋來解釋它在干什么。比如：
   // put elephant1 into fridge2
   put(elephant1, fridge2);
   由于我的函數(shù)名put，加上兩個有意義的變量名elephant1和fridge2，已經(jīng)說明了這是在干什么（把大象放進冰箱），所以上面那句注釋完全沒有必要。

2. 局部變量應(yīng)該盡量接近使用它的地方。有些人喜歡在函數(shù)最開頭定義很多局部變量，然后在下面很遠的地方使用它，就像這個樣子：
   void foo() {
   ?int index = ...;
   ?...
   ?...
   ?bar(index);
   ?...
   }
   由于這中間都沒有使用過index，也沒有改變過它所依賴的數(shù)據(jù)，所以這個變量定義，其實可以挪到接近使用它的地方：
   void foo() {
   ?...
   ?...
   ?int index = ...;
   ?bar(index);
   ?...
   }
   這樣讀者看到bar(index)，不需要向上看很遠就能發(fā)現(xiàn)index是如何算出來的。而且這種短距離，可以加強讀者對于這里的“計算順序”的理解。否則如果index在頂上，讀者可能會懷疑，它其實保存了某種會變化的數(shù)據(jù)，或者它后來又被修改過。如果index放在下面，讀者就清楚的知道，index并不是保存了什么可變的值，而且它算出來之后就沒變過。
   如果你看透了局部變量的本質(zhì)——它們就是電路里的導(dǎo)線，那你就能更好的理解近距離的好處。變量定義離用的地方越近，導(dǎo)線的長度就越短。你不需要摸著一根導(dǎo)線，繞來繞去找很遠，就能發(fā)現(xiàn)接收它的端口，這樣的電路就更容易理解。

3. 局部變量名字應(yīng)該簡短。這貌似跟第一點相沖突，簡短的變量名怎么可能有意義呢？注意我這里說的是局部變量，因為它們處于局部，再加上第2點已經(jīng)把它放到離使用位置盡量近的地方，所以根據(jù)上下文你就會容易知道它的意思：
   比如，你有一個局部變量，表示一個操作是否成功：
   boolean successInDeleteFile = deleteFile("foo.txt");
   if (successInDeleteFile) {
   ?...
   } else {
   ?...
   }
   這個局部變量successInDeleteFile大可不必這么啰嗦。因為它只用過一次，而且用它的地方就在下面一行，所以讀者可以輕松發(fā)現(xiàn)它是deleteFile返回的結(jié)果。如果你把它改名為success，其實讀者根據(jù)一點上下文，也知道它表示”success in deleteFile”。所以你可以把它改成這樣：
   boolean success = deleteFile("foo.txt");
   if (success) {
   ?...
   } else {
   ?...
   }
   這樣的寫法不但沒漏掉任何有用的語義信息，而且更加易讀。successInDeleteFile這種“camelCase”，如果超過了三個單詞連在一起，其實是很礙眼的東西。所以如果你能用一個單詞表示同樣的意義，那當(dāng)然更好。

4. 不要重用局部變量。很多人寫代碼不喜歡定義新的局部變量，而喜歡“重用”同一個局部變量，通過反復(fù)對它們進行賦值，來表示完全不同意思。比如這樣寫：
   String msg;
   if (...) {
   ?msg = "succeed";
   ?log.info(msg);
   } else {
   ?msg = "failed";
   ?log.info(msg);
   }
   雖然這樣在邏輯上是沒有問題的，然而卻不易理解，容易混淆。變量msg兩次被賦值，表示完全不同的兩個值。它們立即被log.info使用，沒有傳遞到其它地方去。這種賦值的做法，把局部變量的作用域不必要的增大，讓人以為它可能在將來改變，也許會在其它地方被使用。更好的做法，其實是定義兩個變量：
   if (...) {
   ?String msg = "succeed";
   ?log.info(msg);
   } else {
   ?String msg = "failed";
   ?log.info(msg);
   }
   由于這兩個msg變量的作用域僅限于它們所處的if語句分支，你可以很清楚的看到這兩個msg被使用的范圍，而且知道它們之間沒有任何關(guān)系。

5. 把復(fù)雜的邏輯提取出去，做成“幫助函數(shù)”。有些人寫的函數(shù)很長，以至于看不清楚里面的語句在干什么，所以他們誤以為需要寫注釋。如果你仔細觀察這些代碼，就會發(fā)現(xiàn)不清晰的那片代碼，往往可以被提取出去，做成一個函數(shù)，然后在原來的地方調(diào)用。由于函數(shù)有一個名字，這樣你就可以使用有意義的函數(shù)名來代替注釋。舉一個例子：
   ...
   // put elephant1 into fridge2
   openDoor(fridge2);
   if (elephant1.alive()) {
   ?...
   } else {
   ? ...
   }
   closeDoor(fridge2);
   ...
   如果你把這片代碼提出去定義成一個函數(shù)：
   void put(Elephant elephant, Fridge fridge) {
   ?openDoor(fridge);
   ?if (elephant.alive()) {
   ? ?...
   ?} else {
   ? ? ...
   ?}
   ?closeDoor(fridge);
   }
   這樣原來的代碼就可以改成：
   ...
   put(elephant1, fridge2);
   ...
   更加清晰，而且注釋也沒必要了。

6. 把復(fù)雜的表達式提取出去，做成中間變量。有些人聽說“函數(shù)式編程”是個好東西，也不理解它的真正含義，就在代碼里大量使用嵌套的函數(shù)。像這樣：
   Pizza pizza = makePizza(crust(salt(), butter()),
   ? topping(onion(), tomato(), sausage()));
   這樣的代碼一行太長，而且嵌套太多，不容易看清楚。其實訓(xùn)練有素的函數(shù)式程序員，都知道中間變量的好處，不會盲目的使用嵌套的函數(shù)。他們會把這代碼變成這樣：
   Crust crust = crust(salt(), butter());
   Topping topping = topping(onion(), tomato(), sausage());
   Pizza pizza = makePizza(crust, topping);
   這樣寫，不但有效地控制了單行代碼的長度，而且由于引入的中間變量具有“意義”，步驟清晰，變得很容易理解。

7. 在合理的地方換行。對于絕大部分的程序語言，代碼的邏輯是和空白字符無關(guān)的，所以你可以在幾乎任何地方換行，你也可以不換行。這樣的語言設(shè)計是個好東西，因為它給了程序員自由控制自己代碼格式的能力。然而，它也引起了一些問題，因為很多人不知道如何合理的換行。